OSuX Bloat

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Nov 7, 2008.

  1. It's not just Microsoft that needs to learn about modularity and package
    management...

    <http://arstechnica.com/journals/apple.ars/2008/11/05/five-ways-to-slim-down-your-mac-os-x-install>
    Lawrence D'Oliveiro, Nov 7, 2008
    #1
    1. Advertising

  2. In <gf040l$gc1$> Lawrence D'Oliveiro wrote:
    > It's not just Microsoft that needs to learn about modularity and
    > package management...
    >
    > <http://arstechnica.com/journals/apple.ars/2008/11/05/five-ways-to-
    > slim-down-your-mac-os-x-install>


    Did we read the same article? Things like unneeded languages or binaries
    for a different processor can be easily removed in Mac OS X precisely
    because of the modular design.

    --
    Roger Johnstone, Invercargill, New Zealand -> http://roger.geek.nz
    Roger Johnstone, Nov 7, 2008
    #2
    1. Advertising

  3. In message <>, Roger Johnstone
    wrote:

    > In <gf040l$gc1$> Lawrence D'Oliveiro wrote:
    >
    >> It's not just Microsoft that needs to learn about modularity and
    >> package management...
    >>
    >> <http://arstechnica.com/journals/apple.ars/2008/11/05/five-ways-to-
    >> slim-down-your-mac-os-x-install>

    >
    > Did we read the same article?


    I read the reader comments warning against doing some of the things in the
    article.

    > Things like unneeded languages or binaries for a different processor can
    > be easily removed in Mac OS X precisely because of the modular design.


    Not so easily, and not without risk to the integrity of your system.
    Lawrence D'Oliveiro, Nov 7, 2008
    #3
  4. In <gf0qd4$tt7$> Lawrence D'Oliveiro wrote:
    > In message <>, Roger
    > Johnstone wrote:
    >
    >> In <gf040l$gc1$> Lawrence D'Oliveiro wrote:
    >>
    >>> It's not just Microsoft that needs to learn about modularity and
    >>> package management...
    >>>
    >>> <http://arstechnica.com/journals/apple.ars/2008/11/05/five-ways-to-
    >>> slim-down-your-mac-os-x-install>

    >>
    >> Did we read the same article?

    >
    > I read the reader comments warning against doing some of the things in
    > the article.
    >
    >> Things like unneeded languages or binaries for a different processor
    >> can be easily removed in Mac OS X precisely because of the modular
    >> design.

    >
    > Not so easily, and not without risk to the integrity of your system.


    From the comments there appear to be three possible problems:

    Removing languages from Microsoft Office causes its updater to stop
    working. That's a buggy third-party updater.
    Removing unused CPU binaries from Adobe apps cause them to stop working.
    That's a third-party security measure.
    Apples applications supplied with 10.5 are code-signed and the OS will
    stop treating them as trusted applications if you modify the binaries
    inside the application packages. The binary (i.e. program code) is
    generally a fairly small part of modern applications though, and you can
    still modify the non-binary resources like languages with no problem.

    --
    Roger Johnstone, Invercargill, New Zealand -> http://roger.geek.nz
    Roger Johnstone, Nov 7, 2008
    #4
  5. In message <>, Roger Johnstone
    wrote:

    > In <gf0qd4$tt7$> Lawrence D'Oliveiro wrote:
    >>
    >> In message <>, Roger
    >> Johnstone wrote:
    >>
    >>> In <gf040l$gc1$> Lawrence D'Oliveiro wrote:
    >>>
    >>>> It's not just Microsoft that needs to learn about modularity and
    >>>> package management...
    >>>>
    >>>> <http://arstechnica.com/journals/apple.ars/2008/11/05/five-ways-to-
    >>>> slim-down-your-mac-os-x-install>
    >>>
    >>> Did we read the same article?

    >>
    >> I read the reader comments warning against doing some of the things in
    >> the article.
    >>
    >>> Things like unneeded languages or binaries for a different processor
    >>> can be easily removed in Mac OS X precisely because of the modular
    >>> design.

    >>
    >> Not so easily, and not without risk to the integrity of your system.

    >
    > From the comments there appear to be three possible problems:
    >
    > Removing languages from Microsoft Office causes its updater to stop
    > working. That's a buggy third-party updater.
    > Removing unused CPU binaries from Adobe apps cause them to stop working.
    > That's a third-party security measure.
    > Apples applications supplied with 10.5 are code-signed and the OS will
    > stop treating them as trusted applications if you modify the binaries
    > inside the application packages.


    Such a lengthy litany of lame excuses for why OS X is not modular.

    > The binary (i.e. program code) is generally a fairly small part of modern
    > applications though, and you can still modify the non-binary resources
    > like languages with no problem.


    Except there were problems, as mentioned in the reader comments.
    Lawrence D'Oliveiro, Nov 7, 2008
    #5
  6. In <gf253k$nf1$> Lawrence D'Oliveiro wrote:
    > In message <>, Roger
    > Johnstone wrote:
    >
    >> In <gf0qd4$tt7$> Lawrence D'Oliveiro wrote:
    >>>
    >>> In message <>, Roger
    >>> Johnstone wrote:
    >>>
    >>>> In <gf040l$gc1$> Lawrence D'Oliveiro wrote:
    >>>>
    >>>>> It's not just Microsoft that needs to learn about modularity and
    >>>>> package management...
    >>>>>
    >>>>> <http://arstechnica.com/journals/apple.ars/2008/11/05/five-ways-to-
    >>>>> slim-down-your-mac-os-x-install>
    >>>>
    >>>> Did we read the same article?
    >>>
    >>> I read the reader comments warning against doing some of the things
    >>> in the article.
    >>>
    >>>> Things like unneeded languages or binaries for a different
    >>>> processor can be easily removed in Mac OS X precisely because of
    >>>> the modular design.
    >>>
    >>> Not so easily, and not without risk to the integrity of your system.

    >>
    >> From the comments there appear to be three possible problems:
    >>
    >> Removing languages from Microsoft Office causes its updater to stop
    >> working. That's a buggy third-party updater.
    >> Removing unused CPU binaries from Adobe apps cause them to stop
    >> working. That's a third-party security measure. Apples applications
    >> supplied with 10.5 are code-signed and the OS will stop treating them
    >> as trusted applications if you modify the binaries inside the
    >> application packages.

    >
    > Such a lengthy litany of lame excuses for why OS X is not modular.


    I gave a whopping three explanations for the different problems
    encountered. Two are purely due to third-party software where it
    wouldn't make any difference whatsoever on which OS the software was
    running, leaving a grand total of one problem that's caused by the way
    Apple does things, and which is actually a security feature.

    >> The binary (i.e. program code) is generally a fairly small part of
    >> modern applications though, and you can still modify the non-binary
    >> resources like languages with no problem.

    >
    > Except there were problems, as mentioned in the reader comments.


    That's the price you pay for a more secure OS. The alternative would be
    for the OS to constantly ask for the user to allow or deny certain
    actions, which I imagine would quickly become tiring.

    --
    Roger Johnstone, Invercargill, New Zealand -> http://roger.geek.nz
    Roger Johnstone, Nov 7, 2008
    #6
  7. In message <>, Roger Johnstone
    wrote:

    > In <gf253k$nf1$> Lawrence D'Oliveiro wrote:
    >
    >> Such a lengthy litany of lame excuses for why OS X is not modular.

    >
    > I gave a whopping three explanations for the different problems
    > encountered.


    "Explanations" which don't change the simple fact that customizing an OS X
    install is not a straightforward matter.

    > ... leaving a grand total of one problem that's caused by the way
    > Apple does things, and which is actually a security feature.


    "Security" for whom? Sounds like a copy-protection feature to protect Apple,
    not the user.

    >> Except there were problems, as mentioned in the reader comments.

    >
    > That's the price you pay for a more secure OS. The alternative would be
    > for the OS to constantly ask for the user to allow or deny certain
    > actions, which I imagine would quickly become tiring.


    Except that other OSes can be as secure, or even more so, without wearing
    down the user with confirmation fatigue.
    Lawrence D'Oliveiro, Nov 9, 2008
    #7
  8. In <gf5d0e$lfk$> Lawrence D'Oliveiro wrote:
    > In message <>, Roger
    > Johnstone wrote:
    >
    >> In <gf253k$nf1$> Lawrence D'Oliveiro wrote:
    >>
    >>> Such a lengthy litany of lame excuses for why OS X is not modular.

    >>
    >> I gave a whopping three explanations for the different problems
    >> encountered.

    >
    > "Explanations" which don't change the simple fact that customizing an
    > OS X install is not a straightforward matter.


    No, customising an install is simple. These are people who are trying to
    modify an already installed Mac OS X.

    >> ... leaving a grand total of one problem that's caused by the way
    >> Apple does things, and which is actually a security feature.

    >
    > "Security" for whom? Sounds like a copy-protection feature to protect
    > Apple, not the user.


    No, it's not a copy protection feature. As I understand it security
    features like the firewall or Keychain password manager use code signing
    to verify the identity of a trusted application. Previously they signed
    the apps themselves, but this meant if the app was modified in any way,
    for example by an update, the user had to be asked for confirmation that
    the app had changed and they still trusted it. Starting with Leopard (10.
    5) Apple signs all the apps they ship with the OS, and software
    developers are encouraged to sign their apps too. The advantage of these
    code signed apps is that when they are updated the OS can confirm their
    authenticity itself, so doesn't need to prompt the user.

    >>> Except there were problems, as mentioned in the reader comments.

    >>
    >> That's the price you pay for a more secure OS. The alternative would
    >> be for the OS to constantly ask for the user to allow or deny certain
    >> actions, which I imagine would quickly become tiring.

    >
    > Except that other OSes can be as secure, or even more so, without
    > wearing down the user with confirmation fatigue.


    Interesting, how do other OSes do it?

    --
    Roger Johnstone, Invercargill, New Zealand -> http://roger.geek.nz
    Roger Johnstone, Nov 11, 2008
    #8
  9. In message <>, Roger Johnstone
    wrote:

    > In <gf5d0e$lfk$> Lawrence D'Oliveiro wrote:
    >
    >> In message <>, Roger
    >> Johnstone wrote:
    >>
    >>> In <gf253k$nf1$> Lawrence D'Oliveiro wrote:
    >>>
    >>>> Such a lengthy litany of lame excuses for why OS X is not modular.
    >>>
    >>> I gave a whopping three explanations for the different problems
    >>> encountered.

    >>
    >> "Explanations" which don't change the simple fact that customizing an
    >> OS X install is not a straightforward matter.

    >
    > No, customising an install is simple. These are people who are trying to
    > modify an already installed Mac OS X.


    Because they couldn't customize the install.

    >>> ... leaving a grand total of one problem that's caused by the way
    >>> Apple does things, and which is actually a security feature.

    >>
    >> "Security" for whom? Sounds like a copy-protection feature to protect
    >> Apple, not the user.

    >
    > No, it's not a copy protection feature. As I understand it security
    > features like the firewall or Keychain password manager use code signing
    > to verify the identity of a trusted application.


    That's not the way to do it.

    >>>> Except there were problems, as mentioned in the reader comments.
    >>>
    >>> That's the price you pay for a more secure OS. The alternative would
    >>> be for the OS to constantly ask for the user to allow or deny certain
    >>> actions, which I imagine would quickly become tiring.

    >>
    >> Except that other OSes can be as secure, or even more so, without
    >> wearing down the user with confirmation fatigue.

    >
    > Interesting, how do other OSes do it?


    In Linux/Unix as an example, most apps run as an ordinary user. No need for
    root privileges, hence no need to ask for them.
    Lawrence D'Oliveiro, Nov 12, 2008
    #9
  10. In <gfdqbg$nr9$> Lawrence D'Oliveiro wrote:
    > In message <>, Roger
    > Johnstone wrote:
    >
    >> In <gf5d0e$lfk$> Lawrence D'Oliveiro wrote:
    >>
    >>> In message <>, Roger
    >>> Johnstone wrote:
    >>>
    >>>> In <gf253k$nf1$> Lawrence D'Oliveiro wrote:
    >>>>
    >>>>> Such a lengthy litany of lame excuses for why OS X is not modular.
    >>>>
    >>>> I gave a whopping three explanations for the different problems
    >>>> encountered.
    >>>
    >>> "Explanations" which don't change the simple fact that customizing
    >>> an OS X install is not a straightforward matter.

    >>
    >> No, customising an install is simple. These are people who are trying
    >> to modify an already installed Mac OS X.

    >
    > Because they couldn't customize the install.


    You can customise an install. For example you can choose which languages
    are installed for the Apple applications. You can't choose which
    processor binaries are installed though, probably because they take up
    comparitively little room and because very, very few users would have
    any idea what they are or why they would or wouldn't want to install
    them.

    >>>> ... leaving a grand total of one problem that's caused by the way
    >>>> Apple does things, and which is actually a security feature.
    >>>
    >>> "Security" for whom? Sounds like a copy-protection feature to
    >>> protect Apple, not the user.

    >>
    >> No, it's not a copy protection feature. As I understand it security
    >> features like the firewall or Keychain password manager use code
    >> signing to verify the identity of a trusted application.

    >
    > That's not the way to do it.


    Because?

    >>>>> Except there were problems, as mentioned in the reader comments.
    >>>>
    >>>> That's the price you pay for a more secure OS. The alternative
    >>>> would be for the OS to constantly ask for the user to allow or deny
    >>>> certain actions, which I imagine would quickly become tiring.
    >>>
    >>> Except that other OSes can be as secure, or even more so, without
    >>> wearing down the user with confirmation fatigue.

    >>
    >> Interesting, how do other OSes do it?

    >
    > In Linux/Unix as an example, most apps run as an ordinary user. No
    > need for root privileges, hence no need to ask for them.


    As I'm sure you're aware Mac OS X is the same. The code signing has
    nothing to do with root privileges. OS updaters (including Linux)
    typically use code signing to verify that downloaded updates haven't
    been tampered with. Apple also now uses it to verify that applications
    haven't been tampered with without the user's permission.

    More information on how it works:
    http://www.atomicbird.com/blog/2007/11/leopard-code-signing-questions-
    and-answers
    http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/11

    --
    Roger Johnstone, Invercargill, New Zealand -> http://roger.geek.nz
    Roger Johnstone, Nov 13, 2008
    #10
  11. Roger Johnstone wrote:

    > In <gfdqbg$nr9$> Lawrence D'Oliveiro wrote:
    >
    >> In message <>, Roger
    >> Johnstone wrote:
    >>>
    >>> No, it's not a copy protection feature. As I understand it security
    >>> features like the firewall or Keychain password manager use code
    >>> signing to verify the identity of a trusted application.

    >>
    >> That's not the way to do it.

    >
    > Because?


    Look at the way Linux package-management systems do it: the digital signing doesn't prevent you from customizing things however you like--it's your choice, you have the last word, not the platform vendor.

    >>>> Except that other OSes can be as secure, or even more so, without
    >>>> wearing down the user with confirmation fatigue.
    >>>
    >>> Interesting, how do other OSes do it?

    >>
    >> In Linux/Unix as an example, most apps run as an ordinary user. No
    >> need for root privileges, hence no need to ask for them.

    >
    > As I'm sure you're aware Mac OS X is the same. The code signing has
    > nothing to do with root privileges. OS updaters (including Linux)
    > typically use code signing to verify that downloaded updates haven't
    > been tampered with. Apple also now uses it to verify that applications
    > haven't been tampered with without the user's permission.


    Like I said, that's not the way to do it.
    Lawrence D'Oliveiro, Nov 13, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eric

    SSH/SSL Code Bloat

    Eric, Feb 12, 2004, in forum: Computer Security
    Replies:
    0
    Views:
    492
  2. 16bit photoshop files: why do they bloat?

    , Feb 19, 2005, in forum: Digital Photography
    Replies:
    10
    Views:
    434
  3. T.N.O. - Dave.net.nz

    Open Office file bloat

    T.N.O. - Dave.net.nz, Feb 13, 2004, in forum: NZ Computing
    Replies:
    7
    Views:
    334
  4. Dave - Dave.net.nz

    printed docs bloat to ~5x the size

    Dave - Dave.net.nz, Dec 13, 2004, in forum: NZ Computing
    Replies:
    12
    Views:
    534
    Nomad Damon
    Dec 14, 2004
  5. Lawrence D'Oliveiro

    OSux Permission Screwups

    Lawrence D'Oliveiro, Sep 7, 2009, in forum: NZ Computing
    Replies:
    0
    Views:
    329
    Lawrence D'Oliveiro
    Sep 7, 2009
Loading...

Share This Page