My biggest concern (more than download size or disk usage) is the working set size. By packaging two separate sets of libs, this is increased. But also the massive reliance on scripting and XUL means that the parsers convert one shared XUL file and one shared js file into big data structures for each instance of the application (no wonder these applications are lumbering single process monstrosities).
I would like to see a XUL parser process that runs a sort of setgid (but I think the current concept is not what I'm looking for). This builds a shared lib for each of the applications XUL and js files caching the result of parsing and possibly compiling them so all instances use that one shared file.
the/usr and/usr/local distinction is normally that/usr will *not* be different from one machine to another at a site or in an organisation, while/usr/local often is.
and / is where you find things that need to be there at early boot, but should be maintained as similar as possible from one machine to another (as if they were/usr).
so you get/bin,/usr/bin, and/usr/local/bin, each for a different purpose, but conceptually really the same place.
I would rather like to see each user home directory have a full heirarchy with directories for shell commands, GUI apps, and libs. These directories would be virtual directories built from a set of rules for the interface that user needs/wants/must have. Thus, an application can have its libs all found under it while they really just refer to a "system" lib.
There *must* be a way to ensure that you can make all those libs point to new versions for security updates, but allow certain exceptions. This requires sophisticated administration tools that I don't know exactly what they should look like. The important considerations are memory/disk usage of such a scheme, and time/space complexity of the administration tasks.
>> One, you lose the benefit of shared libraries. > Which was what, again?
Mainly that the second linking in of the shared lib uses very little extra memory. That means users can all use the same computer with dumb terminals (an attractive proposition for the corporate desktop). It is only with Windows being (untill recently) totally unsuitable for such a purpose that it is not commonly done anymore.
If GTK were installed over and over for each GTK based app, it wouldn't be long till even big iron fell to its knees.
Also, that would end up leaving old insecure libraries around. If App A installs libPNG, then a buffer overflow is found in it, you have to wait for the publisher of App A to bother to issue an update, instead of the publisher of libPNG.
This method also discourages buggy and non-upward compatible libraries since application writers will shun stuff that will break their apps later. They are thus also encouraged to understand that they should report and maybe help fix bugs in libs instead of working around them (which later causes their app to break). It essentially discourages sloppy "lets make a quick buck" abuse of other peoples computers.
I feel I should make the context of my comment more clear:
> Macromedia Flash can use the fscommand action to control the playback and appearance of standalone projectors, as well as launch external applications
Controlling a projector and launching external applications sounds like it has the run of the local machine. If Macromedia have chosen to use overloaded market-speak to give the appearance of explaining a technical mechanism then I retract my concerns.
What about when the local daemon refuses to start. A simple text file can be trivially altered, and the programs to read them are remarkably simple, and thus robust.
A filesystem will get stressed an awful lot more than an LDAP daemon, of that I am certain.
A pure LDAP login solution has some very important advantages over a pure flat file login solution, but when you have PAM, a lot of the advantages disappear.
The only significant one remaining is that authentication can be done over the network via the LDAP protocol (which is pretty nice).
It would be nice to see support of an LDAP daemon to use/etc/passwd and/etc/shadow to provide network wide authentication, but allow a PAM backend to use a straightforward flat file parser for local logins. That way, if the LDAP daemon won't start for some reason (misconfiguration or something), local logins will continue to work as normal. Also using a cache of logins on the client machines in flat files for when the LDAP server doesn't respond - for those cases where there is a local filesystem, or root login for administration may be required.
But you have the right idea, in that distro's should make support for LDAP auth via a remote server trivial to configure, and make the ability to run an LDAP auth server trivial (taking auth data from any of the common local means - so you don't *have* to use a possibly unreliable database as storage).
The only other advantage is that of time complexity for logins... a flat file is O(n), while a good database backend is probably *technically* O(n), but for a hashtable index - though it could be O(n.log n). This is most significant for network auth as mentioned, as that is where n gets large enough to really matter.
>/etc/passwd and friends need to go out. ldap all the way. We also need user/admin friendly ldap tools (in fact I have run my desktop system without/etc/passwd for several months, it's not that hard).
Never underestimate the utility of plaintext files. They have a tendancy to not go wrong (since the filesystem gets remarkably well stress-tested, and an LDAP daemon doesn't). Having said that, I agree, LDAP would be nice. And having said that PAM is even better, it means you can plug in support for whatever system you want - and Linux already has PAM:)
I wonder if that sudhian is carring a 'sploit. I went with javascript enabled (loaded both at the same time though, so it *could* be anandtech). Fortunately, running Linux, there is no fscommand protocol, but if that fs stands for filesystem - then boy am I glad my browser doesn't support it.
Doesn't seem to be happening with javascript disabled.
Uh, exec'ing doesn't require any brow sweat. You just set the fd flags with fcntl to mask out FD_CLOEXEC, then put the fd number on the arguments list. The problem is that no normal programs accept files in that manner (they all require paths).
For daemons that accept a path over a byte stream, you will have to modify them to use a unix socket and pass an fd over it. This needs to be made simpler so that people will use it. Significantly, this does *not* require a global fd-space.
For daemons that use an inet socket you'll have to stop deciding that a given path is the correct one in the client before finally telling the daemon. Instead, have the daemon open the path, then send whatever data is necessary to the client for it to check that this is the required file. But this change would only be needed in the most peculiar of circumstances in weird network applications (as single-system-image machines can use the unix socket approach outlined above).
There are alternatives, such as ensuring that the file that the path refers to cannot change, but that requires mandatory directory locking (v bad), or transactions with each file operation having an argument indicating which transaction it is part of (nearly as bad). Those solutions require timeouts for the lock/transaction, and a way to ensure the lock/transaction has not expired before committing to using the path.
Other than that, a read only directory or such a complex system that an attacker cannot find the route through change/escalation of priviledges to be able to exploit such a potential race condition. This is also a terrible solution as it makes programming of even simple systems a nightmare, and it is difficult to know that you *have* made it complicated to attack. The best solution is to make it easy to eliminate the race and standardise throughout the system utilities.
After choosing a file to be manipulated by an exec'd process, the standard utilities all require a path to the file, instead of leaving the file open and passing the fd number on the commandline. Linux nearly has the infrastructure to handle this correctly with the existing tools and their command line interfaces by abusing/proc.
The shell needs further enhancement to make this clean so it is reasonable to expect people to write multi-process and multi-binary programs securely.
I beleive IBM has partnered with AMD for a reason. IBM will keep AMD up, pushing them to eat away at intels stature at great loss to AMD. Then, shortly before AMD dies, IBM will give the POWER architecture PC compatibility and flood the server and corporate markets with superior technology along with cast-iron "no risk to the corporate purchaser" marketing. IBM will do this with the aid of Microsoft making POWER versions of Windows by promising to shit on Linux.
2) partial check - palettes and tools can be grouped into a single window - images should be separated into tasks but most certainly *not* according to which OS process is handling input and output for that window. Multiple desktops helps though it needs some integration.
3) dunno
4) agree wholheartedly. make it something that does not include any indication of what OS/desktop/GUI toolkit it uses or was originally designed to be used with. (I hate Kthis, Gthat, and TuxTheOther).
IBM created intellectual property and distributed patches (now included in Linux) implementing that intellectual property in Linux.
SCO claims that IBM entered into a contract with AT&T whereby they agreed to grant ownership of all intellectual property that they joined with any of the System V source code while producing their implementation of a UNIX like system. Thus SCO claims that they have the right to restrict the use of Linux and its source code even though the intellectual property that IBM supplied to Linus Torvalds did not include any System V source code.
The claims that SCO makes in court are quite different to those made in the popular press, so I may have some crossover in the above summary. It is also not yet clear from the court procedings that I have read about on groklaw.net whether The SCO Group (SCOX) has shown that they are the successor in interest to the System V copyrights or other intellectual property. It is also instructive to realise that while SCO claims ownership of UNIX, the contract they use in their case apparently discusses ownership of System V only, not all UNIX branded software.
Also, the court case *may* not have any bearing on SCOs right to restrict the use or distribution of Linux. Since it may be that it is only a promise of secrecy that IBM is accused of breaching, and not a promise of transferral of IP ownership. I am not quite clear on this matter.
That's okay, most Windows software promises that your supplier will refund you if you don't agree to the license... So you refuse to agree to any license on it once you've found out it doesn't work, and return it.
> Complete music management with Lsongs to import, organize, play and burn CDs of your favorite music Networking PCs and Printers: Share files and printers between Linspire OS and Microsoft Windows systems Plug-n-Play peripheral support
If this were in the UK, it would have to have a cd-burner (or it wouldn't have complete music management such that you can burn CDs)
AFAIK there is effort underway, but most of the programmers are from a commercial shop so the quality of the software engineering is mostly unimportant.
If you want it to transform into decently engineered software, they need more volunteer developers (who care about the aesthetics and generality of software) or more developers from committed Open Source companies.
The Base app is faulty for me. Haven't figured out whats causing it yet. I suspect a UI flaw since the Tables button renders wrong. I can't help thinking they've pissed about misusing the GUI APIs there.
> The oo people obviously are horrible UI programmers (being open source programmers and all)
Actually they are mostly Sun Microsystems programmers and the UI is predominantly from StarOffice, a commercial program (so it really *is* no suprise that the whole suite has been totally crap for quite some time and is only now starting to improve).
Commercial software is almost all totally shitty, and I rate Open Source much higher - at least the stuff with a user base of programmers since they are willing to join in by making reasonably complete feature suggestions. Whilst non-programmers tend to sit back and say "feed me".
Oh wait, damn, you were taking the piss - bugger. Well I'm not wasting what I've written, so...
IMHO google shouldn't be the international standard moral censor of the web.
As a concerned parent (I'm not, but pretend) I wanted to help protect my teenage daughter so I looked for information by typing "sexual diseases". Granted the search would have worked, but as an unknowledgable home user I thought there were no results.
IMHO, as well as prompting with common queries not involving any sequences of glyphs that the pope might blush at, google suggest should treat people with more respect and also return suggested spelling corrections and search result count for all exact search queries.
At worst, if the user types "cunt", google suggest should include all suggestions with "cunt" in them. And in that case where it is an extremely offensive word to white heterosexual christians (as that appears to be the only metric by which google can be bothered to censor), if the user types it, google should produce suggestions including less offensive words too.
Slashdot Mirror
My biggest concern (more than download size or disk usage) is the working set size. By packaging two separate sets of libs, this is increased. But also the massive reliance on scripting and XUL means that the parsers convert one shared XUL file and one shared js file into big data structures for each instance of the application (no wonder these applications are lumbering single process monstrosities).
I would like to see a XUL parser process that runs a sort of setgid (but I think the current concept is not what I'm looking for). This builds a shared lib for each of the applications XUL and js files caching the result of parsing and possibly compiling them so all instances use that one shared file.
the /usr and /usr/local distinction is normally that /usr will *not* be different from one machine to another at a site or in an organisation, while /usr/local often is.
/usr).
/bin, /usr/bin, and /usr/local/bin, each for a different purpose, but conceptually really the same place.
and / is where you find things that need to be there at early boot, but should be maintained as similar as possible from one machine to another (as if they were
so you get
I would rather like to see each user home directory have a full heirarchy with directories for shell commands, GUI apps, and libs. These directories would be virtual directories built from a set of rules for the interface that user needs/wants/must have. Thus, an application can have its libs all found under it while they really just refer to a "system" lib.
There *must* be a way to ensure that you can make all those libs point to new versions for security updates, but allow certain exceptions. This requires sophisticated administration tools that I don't know exactly what they should look like. The important considerations are memory/disk usage of such a scheme, and time/space complexity of the administration tasks.
>> One, you lose the benefit of shared libraries.
> Which was what, again?
Mainly that the second linking in of the shared lib uses very little extra memory. That means users can all use the same computer with dumb terminals (an attractive proposition for the corporate desktop). It is only with Windows being (untill recently) totally unsuitable for such a purpose that it is not commonly done anymore.
If GTK were installed over and over for each GTK based app, it wouldn't be long till even big iron fell to its knees.
Also, that would end up leaving old insecure libraries around. If App A installs libPNG, then a buffer overflow is found in it, you have to wait for the publisher of App A to bother to issue an update, instead of the publisher of libPNG.
This method also discourages buggy and non-upward compatible libraries since application writers will shun stuff that will break their apps later. They are thus also encouraged to understand that they should report and maybe help fix bugs in libs instead of working around them (which later causes their app to break). It essentially discourages sloppy "lets make a quick buck" abuse of other peoples computers.
I feel I should make the context of my comment more clear:
> Macromedia Flash can use the fscommand action to control the playback and appearance of standalone projectors, as well as launch external applications
Controlling a projector and launching external applications sounds like it has the run of the local machine. If Macromedia have chosen to use overloaded market-speak to give the appearance of explaining a technical mechanism then I retract my concerns.
What about when the local daemon refuses to start. A simple text file can be trivially altered, and the programs to read them are remarkably simple, and thus robust.
A filesystem will get stressed an awful lot more than an LDAP daemon, of that I am certain.
/etc/passwd and /etc/shadow to provide network wide authentication, but allow a PAM backend to use a straightforward flat file parser for local logins. That way, if the LDAP daemon won't start for some reason (misconfiguration or something), local logins will continue to work as normal. Also using a cache of logins on the client machines in flat files for when the LDAP server doesn't respond - for those cases where there is a local filesystem, or root login for administration may be required.
A pure LDAP login solution has some very important advantages over a pure flat file login solution, but when you have PAM, a lot of the advantages disappear.
The only significant one remaining is that authentication can be done over the network via the LDAP protocol (which is pretty nice).
It would be nice to see support of an LDAP daemon to use
But you have the right idea, in that distro's should make support for LDAP auth via a remote server trivial to configure, and make the ability to run an LDAP auth server trivial (taking auth data from any of the common local means - so you don't *have* to use a possibly unreliable database as storage).
The only other advantage is that of time complexity for logins... a flat file is O(n), while a good database backend is probably *technically* O(n), but for a hashtable index - though it could be O(n.log n). This is most significant for network auth as mentioned, as that is where n gets large enough to really matter.
Great, so the site is using macromedia flash to run a local binary...
> -grafics system and font handling
Spell checker needs standardising.
> /etc/passwd and friends need to go out. ldap all the way. We also need user/admin friendly ldap tools (in fact I have run my desktop system without /etc/passwd for several months, it's not that hard).
:)
Never underestimate the utility of plaintext files. They have a tendancy to not go wrong (since the filesystem gets remarkably well stress-tested, and an LDAP daemon doesn't). Having said that, I agree, LDAP would be nice. And having said that PAM is even better, it means you can plug in support for whatever system you want - and Linux already has PAM
I wonder if that sudhian is carring a 'sploit. I went with javascript enabled (loaded both at the same time though, so it *could* be anandtech). Fortunately, running Linux, there is no fscommand protocol, but if that fs stands for filesystem - then boy am I glad my browser doesn't support it.
Doesn't seem to be happening with javascript disabled.
> My experience with Pentium M is that it clocks down BIG time if you don't plug in the power cord. So much so that the laptop is virtually useless.
Funny, my desktop does the same...
Uh, exec'ing doesn't require any brow sweat. You just set the fd flags with fcntl to mask out FD_CLOEXEC, then put the fd number on the arguments list. The problem is that no normal programs accept files in that manner (they all require paths).
For daemons that accept a path over a byte stream, you will have to modify them to use a unix socket and pass an fd over it. This needs to be made simpler so that people will use it. Significantly, this does *not* require a global fd-space.
For daemons that use an inet socket you'll have to stop deciding that a given path is the correct one in the client before finally telling the daemon. Instead, have the daemon open the path, then send whatever data is necessary to the client for it to check that this is the required file. But this change would only be needed in the most peculiar of circumstances in weird network applications (as single-system-image machines can use the unix socket approach outlined above).
There are alternatives, such as ensuring that the file that the path refers to cannot change, but that requires mandatory directory locking (v bad), or transactions with each file operation having an argument indicating which transaction it is part of (nearly as bad). Those solutions require timeouts for the lock/transaction, and a way to ensure the lock/transaction has not expired before committing to using the path.
Other than that, a read only directory or such a complex system that an attacker cannot find the route through change/escalation of priviledges to be able to exploit such a potential race condition. This is also a terrible solution as it makes programming of even simple systems a nightmare, and it is difficult to know that you *have* made it complicated to attack. The best solution is to make it easy to eliminate the race and standardise throughout the system utilities.
This, rookie, is the price of secure programming.
After choosing a file to be manipulated by an exec'd process, the standard utilities all require a path to the file, instead of leaving the file open and passing the fd number on the commandline. Linux nearly has the infrastructure to handle this correctly with the existing tools and their command line interfaces by abusing /proc.
The shell needs further enhancement to make this clean so it is reasonable to expect people to write multi-process and multi-binary programs securely.
I beleive IBM has partnered with AMD for a reason. IBM will keep AMD up, pushing them to eat away at intels stature at great loss to AMD. Then, shortly before AMD dies, IBM will give the POWER architecture PC compatibility and flood the server and corporate markets with superior technology along with cast-iron "no risk to the corporate purchaser" marketing. IBM will do this with the aid of Microsoft making POWER versions of Windows by promising to shit on Linux.
> it's the GIMP because GNU made it
Yeah, that too.
1) check
2) partial check - palettes and tools can be grouped into a single window - images should be separated into tasks but most certainly *not* according to which OS process is handling input and output for that window. Multiple desktops helps though it needs some integration.
3) dunno
4) agree wholheartedly. make it something that does not include any indication of what OS/desktop/GUI toolkit it uses or was originally designed to be used with. (I hate Kthis, Gthat, and TuxTheOther).
The Gollum CG model is anatomically correct... There is a scene in one of the films where you see his wee willy winkle.
IBM created intellectual property and distributed patches (now included in Linux) implementing that intellectual property in Linux.
SCO claims that IBM entered into a contract with AT&T whereby they agreed to grant ownership of all intellectual property that they joined with any of the System V source code while producing their implementation of a UNIX like system. Thus SCO claims that they have the right to restrict the use of Linux and its source code even though the intellectual property that IBM supplied to Linus Torvalds did not include any System V source code.
The claims that SCO makes in court are quite different to those made in the popular press, so I may have some crossover in the above summary. It is also not yet clear from the court procedings that I have read about on groklaw.net whether The SCO Group (SCOX) has shown that they are the successor in interest to the System V copyrights or other intellectual property. It is also instructive to realise that while SCO claims ownership of UNIX, the contract they use in their case apparently discusses ownership of System V only, not all UNIX branded software.
Also, the court case *may* not have any bearing on SCOs right to restrict the use or distribution of Linux. Since it may be that it is only a promise of secrecy that IBM is accused of breaching, and not a promise of transferral of IP ownership. I am not quite clear on this matter.
That's okay, most Windows software promises that your supplier will refund you if you don't agree to the license... So you refuse to agree to any license on it once you've found out it doesn't work, and return it.
This too:
> Complete music management with Lsongs to import, organize, play and burn CDs of your favorite music Networking PCs and Printers: Share files and printers between Linspire OS and Microsoft Windows systems Plug-n-Play peripheral support
If this were in the UK, it would have to have a cd-burner (or it wouldn't have complete music management such that you can burn CDs)
AFAIK there is effort underway, but most of the programmers are from a commercial shop so the quality of the software engineering is mostly unimportant.
If you want it to transform into decently engineered software, they need more volunteer developers (who care about the aesthetics and generality of software) or more developers from committed Open Source companies.
Yeah, it's a lot faster to start and to preload.
The Base app is faulty for me. Haven't figured out whats causing it yet. I suspect a UI flaw since the Tables button renders wrong. I can't help thinking they've pissed about misusing the GUI APIs there.
> The oo people obviously are horrible UI programmers (being open source programmers and all)
Actually they are mostly Sun Microsystems programmers and the UI is predominantly from StarOffice, a commercial program (so it really *is* no suprise that the whole suite has been totally crap for quite some time and is only now starting to improve).
Commercial software is almost all totally shitty, and I rate Open Source much higher - at least the stuff with a user base of programmers since they are willing to join in by making reasonably complete feature suggestions. Whilst non-programmers tend to sit back and say "feed me".
Oh wait, damn, you were taking the piss - bugger. Well I'm not wasting what I've written, so...
>> The company got its start by offering a tool to identify pornographic images
:-)
> Like you need a tool to do this?
I dunno, if you lose your tool in an accident can you still tell what's pornographic and what's just a picture of a pretty lady?
IMHO google shouldn't be the international standard moral censor of the web.
As a concerned parent (I'm not, but pretend) I wanted to help protect my teenage daughter so I looked for information by typing "sexual diseases". Granted the search would have worked, but as an unknowledgable home user I thought there were no results.
IMHO, as well as prompting with common queries not involving any sequences of glyphs that the pope might blush at, google suggest should treat people with more respect and also return suggested spelling corrections and search result count for all exact search queries.
At worst, if the user types "cunt", google suggest should include all suggestions with "cunt" in them. And in that case where it is an extremely offensive word to white heterosexual christians (as that appears to be the only metric by which google can be bothered to censor), if the user types it, google should produce suggestions including less offensive words too.