Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > OSuX Bloat

Reply
Thread Tools

OSuX Bloat

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-07-2008
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>
 
Reply With Quote
 
 
 
 
Roger Johnstone
Guest
Posts: n/a
 
      11-07-2008
In <gf040l$gc1$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
> It's not just Microsoft that needs to learn about modularity and
> package management...
>
> <http://arstechnica.com/journals/appl.../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
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-07-2008
In message <(E-Mail Removed)>, Roger Johnstone
wrote:

> In <gf040l$gc1$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>
>> It's not just Microsoft that needs to learn about modularity and
>> package management...
>>
>> <http://arstechnica.com/journals/appl.../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.

 
Reply With Quote
 
Roger Johnstone
Guest
Posts: n/a
 
      11-07-2008
In <gf0qd4$tt7$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
> In message <(E-Mail Removed)>, Roger
> Johnstone wrote:
>
>> In <gf040l$gc1$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>>
>>> It's not just Microsoft that needs to learn about modularity and
>>> package management...
>>>
>>> <http://arstechnica.com/journals/appl.../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
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-07-2008
In message <(E-Mail Removed)>, Roger Johnstone
wrote:

> In <gf0qd4$tt7$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>>
>> In message <(E-Mail Removed)>, Roger
>> Johnstone wrote:
>>
>>> In <gf040l$gc1$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>>>
>>>> It's not just Microsoft that needs to learn about modularity and
>>>> package management...
>>>>
>>>> <http://arstechnica.com/journals/appl.../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.
 
Reply With Quote
 
Roger Johnstone
Guest
Posts: n/a
 
      11-07-2008
In <gf253k$nf1$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
> In message <(E-Mail Removed)>, Roger
> Johnstone wrote:
>
>> In <gf0qd4$tt7$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>>>
>>> In message <(E-Mail Removed)>, Roger
>>> Johnstone wrote:
>>>
>>>> In <gf040l$gc1$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>>>>
>>>>> It's not just Microsoft that needs to learn about modularity and
>>>>> package management...
>>>>>
>>>>> <http://arstechnica.com/journals/appl.../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
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-09-2008
In message <(E-Mail Removed)>, Roger Johnstone
wrote:

> In <gf253k$nf1$(E-Mail Removed)> 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.
 
Reply With Quote
 
Roger Johnstone
Guest
Posts: n/a
 
      11-11-2008
In <gf5d0e$lfk$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
> In message <(E-Mail Removed)>, Roger
> Johnstone wrote:
>
>> In <gf253k$nf1$(E-Mail Removed)> 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
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      11-12-2008
In message <(E-Mail Removed)>, Roger Johnstone
wrote:

> In <gf5d0e$lfk$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>
>> In message <(E-Mail Removed)>, Roger
>> Johnstone wrote:
>>
>>> In <gf253k$nf1$(E-Mail Removed)> 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.
 
Reply With Quote
 
Roger Johnstone
Guest
Posts: n/a
 
      11-13-2008
In <gfdqbg$nr9$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
> In message <(E-Mail Removed)>, Roger
> Johnstone wrote:
>
>> In <gf5d0e$lfk$(E-Mail Removed)> Lawrence D'Oliveiro wrote:
>>
>>> In message <(E-Mail Removed)>, Roger
>>> Johnstone wrote:
>>>
>>>> In <gf253k$nf1$(E-Mail Removed)> 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/...ing-questions-
and-answers
http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/11

--
Roger Johnstone, Invercargill, New Zealand -> http://roger.geek.nz
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
OSux Permission Screwups Lawrence D'Oliveiro NZ Computing 0 09-07-2009 03:11 AM
Which causes more code-bloat: inline virtual or template class? RainBow C++ 6 08-25-2005 11:47 PM
16bit photoshop files: why do they bloat? digiboy@mailinator.com Digital Photography 10 02-21-2005 10:50 PM
SSH/SSL Code Bloat Eric Computer Security 0 02-12-2004 06:35 PM
STL & reducing code bloat Salvador I. Ducros C++ 5 08-04-2003 11:20 PM



Advertisments