Slashdot Mirror
What's Wrong with Unix?
aaron240 asks: "When Google published the GLAT (Google Labs Aptitude Test) the Unix question was intriguing. They asked an open-ended question about what is wrong with Unix and how you might fix it. Rob Pike touched on the question in his Slashdot interview from October. What insightful answers did the rest of Slashdot give when they applied to work at Google? To repeat the actual question, 'What's broken with Unix? How would you fix it?'"
no, those are eunuchs
I'm the Devil the Windows users warned you about.
If you read the motivations behind writing Plan9 (documented on slashdot previously), there are many descriptions of what the authors thought was wrong with UNIX. And the guys who wrote Plan9 are the same guys who wrote the better part of UNIX. And for you youngsters, UNIX is not LINUX. - AndrewZ
Speak for yourself - for years, I've installed packages in "/usr/local/packages".
Package "foo", version "N" goes in "/usr/local/packages/foo-N".
The current version of "foo" has a symlink to it from "/usr/local/packages/foo".
"/usr/local/bin" contains symlinks to the appropriate files in "/usr/local/packages/*/bin"
Upgrades (and downgrades) are trivial.
I know it sounds silly, but it's like asking a consumer to operate a bradley armoured figting vehicle, it wasn't built for consumer use, its got hundreds of knobs and options and configurations, and if you don't get it set up right the first time it is a tremendous headache to fix it. Consumers want a gas pedal and a brake, windshield wipers are fine, but when you put on a .50cal machine gun mount, even if its "turned off", it scares people away.
It's a canonical example of something that tries to be everything to everybody, but ends up being too hard for anyone to use.
It already exists and is called OS X
Evolution or ID?
No PCL!!!! Reasons:
- PS you can very easily convert to PDF - none for PCL!
- there tons of tools which enables you "4 pages in 1", accounting quotas etc. etc. - none for PCL!
- try to display PCL file
- WHICH PCL? PCL5? PCL3?...
There is simply NO reason to give up - tell me one single argument (except VERY slight speed-up) which will balance the loosen flexibility and necessary to rewrite all existing tools (CUPS, print drivers etc.)
>
>PCL is available on every major printer on the market today - it IS the standard. PostScript is a has-been. Dump it today.
Huh? I think you've got that backwards.
PCL requires that most of the "brains" exist on the "computer" side of the "computer/printer" connection. A PCL printer needs less "brains" than a Postscript printer because all the processing is done on the "computer" side of the connection.
Not to put too fine a point on it, but a PCL printer is to a Postscript printer what a Winmodem is to a hardware modem.
For printers, the PCL tradeoff made a lot of sense sense when embedded CPUs were (extremely) limited in computational power compared with desktop CPUs. Rather than have your $1500 486-33 sitting idle as it dumps a pile of Postscript code to another $1000 68020 in the printer, I'll use my $1500 desktop CPU to turn my document into PCL that can be parsed by the $1.99 Z80 or whatever's in my $100 PCL printer.
Now that your $25 disposable cell phone has a 200 MHz core, that tradeoff is no longer a requirement. Embedded systems smart enough to interpret and run Postscript code are no more (and no less) expensive than those capable only of PCL.
Methinks you've got the PCL/Postscript design tradeoff backwards.
Well to work properly it would also need to have the versioned filesystem of VMS. So if someone were to say overwrite it with zero's then you just revert back to the previous version that wasn't zero's. You see? If the file is deleted the file is gone, but if someone changes the file to be useless, then I could jsut revert it. Make sense? There's no way anyone with only write permission could destroy any part of the system permanently. It's just a one command restore.
/* oops I accidentally made a comment, sorry */
Ideally all confi files would follow the same format and syntax (god no please don't say XML).
Ideally there would be a uniform way for programs to retrieve configuration information from a centrallized location.
Ideally local users and machines would be able to merge their prefs and config with the master to override certain prefs.
Ideally the hierarcy of administrators would be able to prevent entitities under them from overriding certain configuration options.
Ideally all of that could be done with plain text files which are automatically checked into a version control repository so you can roll back any change in a jiffy.
There was a project on sourceforge that adresses some of the points you raise. Originally it was called "Linux-registry" I believe, now it's called Elektra.
I don't know how far they've come or anything about the project, but it looks like something that You'd want to have a look at.
You are not entitled to your opinion. You are entitled to your informed opinion. -- Harlan Ellison
It doesn't even have to be an installer. Ever used OS X? To install software on X, you simply drag a .APP container file into your Applications directory. To uninstall, you drag it to the trash.
How is this not better than the current Unix way of doing things?
OS X also has a package manager, which IMHO, is much more trustworthy than an executable installer. My only real complaint is that so many MAc OS X packages insist on being installed on the main drive. That makes me sad.
even with a package manager, you can't even determine how big a given package is! (if you know how to with Portage, I'd like to know)
equery size package
equery is part of gentoolkit
I'll probably be modded down for this...
> The lack of ACLs is a major impediment to uptake
> of Linux in the business community.
This is not at all insightful. It is uninformed at best. Posix ACLs exist on ext2/3,xfs,reiser,jfs. These ACLs are also completely supported by Samba (and have been for many years).
-Mark
I dunno, maybe you're just trolling (and a number of replies that follow would qualify you as a good troll), but I'd say that installing FreeBSD is not any more difficult than, say, Slackware or Debian. It is more challenging than your Mandrake or RH install, I think (have not had a chance in the last 3-4 years to try either).
That said, with enough preparation and a chapter from the Handbook printed out and within a reach installing stock FreeBSD should not be a problem at all.
The question you should, however, ask yourself is Why do I want to try FreeBSD? If it is just because you've heard it's cool -- you may be much better off trying a http://www.freesbie.org/ instead. It's a live FreeBSD ssytem, sort of like Knoppix.
If you want to give FreeBSD a spin because you want to understand UNIX-land better or have needs for the stability of the platform, then rough starts should not be anything to discourage you.
In either case -- all the best and have fun!
--AP