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?'"
In my opinion, here are some headaches that have plagued a wary UNIX engineer or two:
IEEE and Posix, X/Open, etc. provide a basis for standardizing UNIX interfaces, but adherence tends to be spotty
Difficult to implement a microkernel architecture
XPG3 aside, a de facto "common API" has never really been acheived
In many cases, code scrutiny is difficult or impossible
Progress and innovation tends to occur within the context of aquisitions (i.e. UnixWare)
The COFF symbolic system is terrible (OK, I know it's a deprecated, but still...)
PIT initialization (time management)
Kernel tuning (anyone fiddled with the /etc/conf/cf.d subdir on OS5?)
These are just a few things, in my experience. That said, UNIX has had some great days.
Sigs cause cancer.
'nuff said
-- "If A equals success, then the formula is A=X+Y+Z. X is work. Y is play. Z is keep your mouth shut." - Einstein
I'm used to reading my system text as a white font on a blue background.
Based upon my experience with IRIX and Solaris (with some Linux), I would have to say that most of the things that *NIX did poorly have been rectified with OS X. I would have said OS X was still lacking true 64bitness, but that is coming in 10.4 rather quickly now. The numbers of Macs involved in secure and classified work in the Federal government have been exploding and high bandwidth networking options for cluster computing have also been resolved with options such as Infiniband. Development issues have been streamlined with rather nice tools from Apple itself obtained via NeXT. Open standards are being embraced just about everywhere you turn in OS X, a true plug and play environment now exists (I am reminded of the last video card install on my SGI O2 which had me down for two days solid), the GUI is consistent and the CLI is present and fully integrated with the GUI as well. Additionally, more and more networking options are being supported natively within OS X which is one of the last hurdles to true interconnectivity cross platform. And the G5! Oh, the G5 is a wonderful bit of hardware with which to run *NIX on.
Problems that remain are being able to create one seamless environment with shared memory and such, but the rest of the *NIX world is still having those problems as well.
You can argue about the specifics and details of many things, but in terms of a UNIX workstation, OS X pretty much has it all for our needs.
Visit Jonesblog and say hello.
they have no penis'
I like Unix, but I think I'd add some VMS stuff. Like a Delete attribute. VMS you can set people to have read/write/execute and delete. in unix if people have write, they can write it to "null" *grumble*.
/* oops I accidentally made a comment, sorry */
"I would have spelled "creat" with an "e" on the end..."
The first thing to change should be how programs get installed.
/usr, without a directory, because everybody is too lazy to have /usr/foo/bin and /usr/foo/lib in their respective environment variables, because it's too much of a "pain" to put them in there on software installation, and it makes library linking more difficult.
/usr/lib, /usr/bin, /usr/share, et al.) and there's no good way to do it.
/usr/lib/foo.so -> /usr/local/foo/lib/foo.so, maybe something else, I don't care) to make it so program installation/uninstallation makes more sense.
EVERYTHING right now goes in
Right now, if I want to uninstall a program, I have to remove it from about 10 different places, many of which aren't obvious (/etc,
Find a way (maybe symlinks
//FIXME: Bad
Nothing, you're just not it.
I think the biggest problem with Unix is the lack of standardized way of doing certain things, in particular program configuration. Even simple programs that require very simple configuraiton store it in random places and formats. Not to mention things that require some serious config files, like sendmail, apache or X. Creating a cross-platform powerful configuration language would help.
I passed the Turing test.
Would like to start by expressing my home that this is going to be the best /. thread evar. ^^v
[o]_O
Q. What's wrong with Unix?
A. All those slashes and dots.
Q. How you would fix it?
A. um, slashdot
Of course!
http://tinyurl.com/4ny52
no, those are eunuchs
I'm the Devil the Windows users warned you about.
It's free.
"The fact that I have yet to receive significant monetary compensation for working with it. I would fix it by having someone at Google to hire me with a starting offer of $100,000 per year salary and a signing bonus of options for 50,000 shares of pre-IPO Google stock."
Why are you looking at me like that? I figured all the good jobs were gone, so I was trying for a marketing position.
Google called me a wimp for not answering the non-mathematical questions. At MathWorld News,you can see how Eric and I answered all the other questions.
Printing - more specifically, Postscript Printing.
This sillyness of having to generate postscript so Ghostscript can generate PCL so you can print is just wrong - empty brained, someone forgot to wake up wrong.
PCL is available on every major printer on the market today - it IS the standard. PostScript is a has-been. Dump it today.
That is what is wrong with *nix and what I would do to fix it is require all software to support PCL printing directly.
Ron Gage - Westland, MI
Needs a standard control stream and no ioctl.
While I agree that the core OS has not moved much in decades, I also see very little motivation for this as much of the required functionality has moved up the stack to the application layer.
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
Sigs cause cancer.
Problem: ......
Unix is great!, unless:
- You just want a plug and pray answer
- You just want a word processor
- You just want
If someone is only looking for a single application, it is hard to shove such a versitile system down their throat.
Solution:
Create a truely modular UNIX/OS that does not depend on any single environment(init/SYSV). Make a pluggable API-level interface that you can plug anything from a single application to a complete system environment into. Then get someone to develop EXACTLY what you want.
Idiotware without the bloat.
Laughing all the way,
-- Kei
One big thing that's wrong with Unix is SCO.
C with it's standard null-terminated strings. Bad news all around.
I really like the idea from the article - what's wrong with UNIX is that it's great stand-alone system but once you connect lot of UNIX machines, it's hard to get "all-over-network" filesystem/accounts/desktop enviroment/SW distribution & update/etc. - I know that there are solution for every single thing of this BUT it's always "non-standard" (compared to "stand-alone" UNIX machine) and not-well cooperating solutions...
That is why distributions have package management systems for GNU/Linux. A single command is sufficient to install/remove a package.
However, I understand your problem, when it comes to manual installation. There is a project GNU Stow to handle what you are talking about.
If openness were not a requirement, we would not have the OS landscape we have today, we could have enabled rock-solid computing with any number of non-free alternatives like VMS, AIX, etc
I would suggest to the KSpaceDuel team that they meet with the KAsteroids team to discuss usability issues. There should also be a cap on how fast you can go, since it is possible to speed up so fast that your spacecraft appears to be moving very slowly (sort of like a tire in motion).
Lack of coherent newbie documentation.
Sure, man pages exist, but even once you learn that man does what help really should the man pages are generally written by programmers for programmers.
Newbie guides generally don't get any further than a small command summary, which doesn't really show any strengths of unix over using a gui [or windows!]
The best thing I think would be to provide more "whole system" examples/help rather than help for each individual command. Take some nice simple topics [how to add many users, how to determine network utilization programatically, how to determine open ports and what process is using them...] which are painful to do on windows and use a variety of unix tools to solve them.
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.
Installed base
Chip H.
Jeez, where do I start?
The basic Unix I/O model is that of byte streams flowing around the system, and in and out of devices. Unfortunately, this model really only applies to tape drives; most devices have to be addressed first (such as a disk block number), and then read or written in discrete chunks (blocks, packets).
In the core system what I find most lacking is better support for providing psuedo-kernel type services. For instance windowing systems/3d accelerators end up being interfaced with a bunch of hacks and make use of little to no unified kernel support for this sort of thing.
I've also never been impresed by the IPC facilities in unix, it seems there are a bunch of 'okay' solutions cluttering up the kernel but no really good/modern IPC solution. It would be nice if we could get one protocol with a bunch of options or a few good protocals aimed at certain situations (shared memory models, message passing etc..).
I'm sure there are a few more things that aren't the best deep down in the kernel architecture. For instance many not-super-critical sections of code in linux use bad/stall prone algorithm. However, this isn't a problem in all unices. But other than the above issue the only real disadvantage to the users is lack of software and that isn't really a unix problem.
If you liked this thought maybe you would find my blog nice too:
Jerry
http://www.syslog.org/
I was taking a look at plan 9 and I was impressed by the feature that allows every single process to have a unique perspective of the file system. For example, if a process wants to draw in its window, there is a special file in /dev (I think) that maps on it own window and so on. Features like this are implemented via special handling in normal Unix and are probably rare.
These ideas could perhaps extend the philosophy of "everything is a file" and at the same time improve security.
Hmm... (pondering a bit)... Oh, yeah. Get rid of Unix signals. They are an archaic throwback to when unix had no concept of threading and needed some sort of asynchronous mechanism. But they don't work very well and are lossey. They fixed that with Posix condition variables. If you get rid of Unix signals you will increase the reliability of Unix applications by at least an order of magnitude based on my experience. That's one thing Windows got right. They don't have asynchronous signals.
Seriously, it ain't broke. Been working great for a long, long time. What will make UNIX, *BSD, Linux collectively strong is sticking to the same UNIX plan (as has been the goal with Linux from the start).
It is not easy to use and has no standars. Whenever i sit down at unix/linux/bsd it has ia differtn shell, editor, install place, package system and so on. Decide on a standard and YES PLEASE let theire be a million options but lets use one way on all places.
"To repeat the actual question, 'What's broken with Unix? How would you fix it?"
It doesn't have a nifty name, and it's interface isn't like the leader
Not everyone's running it.
Laugh.
It's a joke.
make it challenging, soft and cuddly, with lots of fire power!!
Yeah, I know that most *nix lover simply love it. But let's face it : this language, which is still the most important one in a unix environment, is really aging. It is possible to develop big software in pure C, but it takes much, much time, and the risk of introducing bugs and security flows is huge. Only the minimal low-level core of the system should be based on C ; the rest should be developed in a modern, high-level language.
Its hard to pinpoint anything specific that is broken with unix as a whole.
But there are lots of subsystems that aren't exactly perfect.
Examples that come to mind:
*File permissions only go to user/group/others rather than individuals, and poor record locking on network shares. Lack of automounting as an intrinsic feature of the operating system.
*Windowing subsystems that network, but cant handle 3d networked graphics effectively, or support the more advanced hardware features of graphics chips locally particulaly well.
*Software packaging systems that develop conflicts. (Probably more of a linux problem, actually)
- I am aware that all of these have workarounds or are being worked on -
The kernel of most unix's (and, for that matter linux) are fairly well tuned to a variety of things, although they are subject to a number of internal revisions to try and do better multi tasking & multiple processor scaling, for example.
Where these systems will probably fail the most is when the underlying hardware changes alot - for example handling larger memory spaces and file systems, or perhaps even moving to whole new processes (eg., code morphing cpu's such as transmeta's, asynchronous cpu's). These designs are quite radically different and we have developed down a specific cpu/memory/harddrive model so far that its quite difficult to look at major changes, as they aren't as easily supported by the operating systems.
Just my 2c, and from a fairly casual observer status - it would be interesting to hear what the main developers think on all of this.
Michael
There is no cryptographic solution to the problem where the intended receiver and the attacker are the same entity.
I know that a lot of people think it is a great thing, but it is really problematic. It makes great sense on systems that have fixed disks, but once you start having transient filesystems (network filesystems or removable drives) it becomes a real problem. If a filesystem is removed then programs may segfault since the mapping disappears. All other entry points for this sort of thing fail at a system call (read or write) which allows for graceful recovery. Conceivably the OS could inform the user or insert a zero filled backing, but that could lead to data corruption.
This is a particularly bad problem for desktop systems, where the users are not experts. For server or cluster systems it is not an issue.
That is part of the problem right there. All of you are talking about a lot of complex issues that the common user knows absolutely nothing about, and no one has mentioned this. How about making it intuitive and simple enough so that my grandmother could use it. Maybe then you'd see more people using it than Windows...
No one cares what your captcha was
Houston TX, USA
In what way does SCOG own unix? They bought a license to sell a version of it and give 95% of the revenue to Novell. And Novell doesn't own the name.
Having said the above however, you do point to a heretofore problem with unix. There were various vendors and flavors of unix. Unix will become open source and standardized. All unix will become posix compliant and everything will be good. (a guy can dream can't he?)
SOLUTION: 2 MT airburst over Lindon, UT
Oh, with UNIX, not for UNIX. Never mind.
As you were.
The help system is one thing Windows XP does better than Linux. Now if I could just get my wife to click on Start/Help instead of calling me up at work and asking me how to use the computer, we'd be all set...
X11
Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
so Darl Mcbride is a eunuch?
theres no groundwork to allow Unix to surf the pervasive wave. instead there's only huge ancient walls which people have been waving their hands at for decades. the wall hasnt noticed. unix is a perfect multi-user base, except one flaw.
X needs a way to allow applications (wm's) to discern the source of input. Built off this core, window managers or X itself can hack solutions to craft "multiple cursors". (Ultimately the window manager is going to have to get deeply involved with this policy; I think the best solution is to simlpy expose the source of input and have the window manager hold state for each input-source and manipulate the single corepointer, "faking" multiple pointers. this prevents X from having to deal with drawing&policy (which is the wm's domain)). Currently the best interaction you can get is to mux together your inputs into one keyboard/mouse pair.
The multiple pointers in X problem has been around for a while, but no ones been able to crack it. X was simply never meant to have more than one cursor, never meant to assuming anything past a single keyboard and mouse.
The one plight of this solution is that every X input event would have to pass through the window manager, which I imagine is expensive.
synergy allows you to share input devices between computers (even cross platform) but the next logical step is missing.
All we need is some way to see the physical source of each input event.
There's no bigger achilles heel.
Myren
Note that it contrasts unix to high-end systems of the day (i.e. Lisp Machines). Windows is even worse than unix, hence it did even better (by some metrics).
/bin and in /appdir , with a categoric, relational or at least freaking set-theoretic file system.
Top of my list: hierarchical filesystem. The Relational Revolution happened, DEAL WITH IT. Hierarchical databases are appalling for data organisation. They should be available as a speed optimisation, but the core filesystem of a next-gen system should be post-hierarchical. My Lords of Acid mpgs should be in "hot" and "dance"... AND I should be able to "ls -x" and AT LEAST SEE that a particular mpg is in BOTH "hot" and "dance".
Most of the problems with application packaging come from the fact we have an assinine hierarchical system on unix - any reasonable system would have application binaries in
Break FREE of hierarchical thinking.
The Unix Hater's Handbook
Yes, the link is hosted on MS servers, but before you ignore it for that, at least notice that the forward is by Dennis Ritchie and it was contributed to primarily by Unix geeks. It's about 10 years old, but large portions of it are still relevent today.
I realize this isn't a standard part of Unix, but as far as I know, none of the Unix/Linux package installation systems makes an effective attempt to enforce limitations on the effects of a broken or malicious installation.
./configure, ./install) assume the install will run as root, even if the actual installed programs are scrupulous about permissions and security. If you're even middling paranoid about security, this is a nightmare!
Many essential packages (whether RPM, Debian, Solaris, or the traditional untar,
A related problem is that there's no guaranteed clean way to remove packages. Yes, they generally do uninstall cleanly, but again that's because the packagers generally do a good job of it. Certainly the Unix Way is better than throwing everything into a big database (read: Registry), but there need to be clean (and enforced!) interfaces that obviate the need to for multiple packages to fiddle with each other's files.
That's a problem with the standard C library, not with Unix. Personally, I'd like to see strcat, strcpy, etc. removed and everyone forced to use the length-checked counterparts (e.g. nstrcat, nstrcpy, etc.)
UNIX and the various shells were designed for when every keystroke counted due to memory constraints and the painful experience of working at a teletype.
As a result, we've got upper- and lower-case flags doing completely different operations (-r and -R for "remove" and "restore," for example), we've got case-sentitive filenames which just make it so easy to tell the difference between "Index," "iNdex," "inDex," "indEx" and "indeX."
UNIX was designed when plain text was king and the only nudies you ever saw were ASCII art.
As a result, there's no way from looking at the filename to tell what program the file should be processed with.
UNIX was designed under the guidelines of "do one thing well, do it quickly and get out of memory."
Those design decisions permeate UNIX and the *NIX community even today. When I read the newsgroups, I still see tips on how to do things that involve piping a file through 17 filters to do something that can be done on Windows with four mouse clicks.
So how would I fix these problems?
1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS."
2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX.
3) Start making UI's that only initially expose the 20% of the UI that 80% of people will use. There's no reason for a CD-burning package to have a checkbox on the main screen about verifying post-gap length for 99% of the people in the world.
Anyway, that's my opinion.
RomSteady - I came, I saw, I tested. GamerTag: RomSteady / http://www.romsteady.net
1. An advanced interprocess architecture, right now almost everything still has to be done will unix sockets 2. The ability to have something like hurd translators. I know linux is monolithic, but user level translators would be a good "nice to have".
Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
-the allmighty root (single largest security risk)
-ancient directory organization which doesn't take modern computer usage into account (more powerfull single workstations)
-bad historically grown naming ("home", "usr", "var", etc.) and incosequent File System Herarchy Standard
-crappy vendor support
-unix printing still sucks big time (see 'vendor support')
-grafics system and font handling
-inconsistent standards of configration
-histrically grown elitist utility naming (large anoyance)
That's all I can come up with right now. Note that some of these are dealt with by certain unix variants. Printing and pretty much everything else is a breeze on OS X for instance. Configuraion and installation with Debian Linux is very smooth and goes great length to keep those countless OSS utilities manageable. And Solaris 10 seems to have the one or other card up its sleve to deal with security risks that result in the allmighty root.
Coming to think of it: Can't we just have an OS with OS X ease of use, Debians installation system, Solaris 10 low-level features and Windows Vendor support? We'd all be set and 100% satisfied.
We suffer more in our imagination than in reality. - Seneca
see http://www.happypenguin.org/ then..
1. Directory structure is very frustrating, especially when moving between FreeBSD, Fedora, Debian, etc. Why can't we have: /private ##for sharing with all people with user accounts /programs ##for shared progs /public ##for sharing with everyone /system /system/dev /system/libs #etc etc /system/programs/ ##for "system" utils /users/$USERNAME/programs ##for user installed programs /users/$USERNAME/documents /users/$USERNAME/preferences
I think permissions would be easier this way.
2. Driver support sucks. Doesn't matter why, it just does. Perhaps we need a standard driver loader that will accept binary files.
3. Installing programs/libs sucks. I like the Apple solution of a directory that includes all dependencies as the "package." But we still need an extendable standard so different installers aren't required for business oriented flavors of *nix.
1. Switching video modes is so backwards in Unix. Windows 3.1 was easier except for selecting bad modes which didn't have a undo feature.
2. library hell
I tried installing Mozilla on a Redhat Linux WS 2.1 system. I gave up after recompiling several library packages.
WhatMeWorry
If you have 1000 files on a unix system, and they are all 90% similar, the system should be able to figure out how to store 90% of those blocks in the same space. And manage them so that none are deleted until all references to them are deleted.
That would take care of all the shared library problems, and all the missing soft link type problems. It would speed up local copying dramatically, and allow applications to copy all the information they use locally without hogging up a bunch of disk.
Also, all programs would be compiled statically, but if they shared the same library blocks as other programs, the system would store those blocks as a single item instead of multiple times. The library managment, and conflicts would be transparent to the programmer and the user.
And when I compile other peoples code, I wouldn't half hunt down 50 zillion other libraries and dependencies. Just the file blocks I don't have. It could even be done automatically on a p2p network in machine clusters to reduce overhead.
md5sum source/file blocks could become standard.
UNIX was obviously originally written as a practical joke - a parody of an operating system, designed with the antithesis of a practical user interface. Instead of setting a goal of being intuitively obvious with command names, consistent in syntax, and using a generous set of defaults, UNIX instead uses a set of counter-intuitive command names, unique syntax for each command, destructive defaults, and no attempt to assist or complete commands for the user. The kernel is equally disfunctional. Nothing is deterministic, there were originally no facilities for giving fixed quotas of CPU, memory or disk to processes. Only general levels of priority. THere were no interrupt handling, no ability to guarantee I/O rates by creating contiguous files. It was like a little childs kindergarten OS. Some of these things have been partially compensated for in proprietary extensions by companies like SGI. BTW- if Linux is ever going to come out of the geek closet and graduate to a widely used OS, it is going to have to divorce its cult-of-UNIX followers and drop the CLI...
"Sic Semper Path of Least Resistance"
install/uninstall
software/os configuration
uniformity of interface
no automatic system restore
system directory sturcture
I don't want unix to be Windows, but why make it difficult when it doesn't need to be. An OS should get out of your way, but still get everything done.
-rich
Friends don't help friends install M$ junk.
In case no one else mentions it, the single biggest flaw for the unix programmer is the lack of thought between some of the inteprocess mechanisms. In particular, the fact that selects only work on files but not semaphores or message queues. This results in having to choose one mechism or the other and thus compromised designs. That and the whole idea of dup which simply uses the next available file descriptor and thus forced semaphores and others not to be able to use file descriptors to implement which would have removed my first complaint.
--Karl
This guy is spamming his url. I have sig's turned off and it keep's showing up. Mod this spammer down.
Genetialia. I don't want to even try to fix those. /lol
while(1) { fork(); };
requires some real study before it's usefull, nothing is more anti-user friendly than a prompt and no hint about what to do next. All usefull UNIX,s have the UNIX hidden behind a user friendly mask.
There was an unknown error in the submission.
I can't get windows updates to work on it.
It will not run well on the first computer I slaved away for. DELL Service Code: 696ML
? fuse=71
GNU all the way baby.
Revenge
http://www.legaltorrents.com/index.php
It's called "OS X".
How does OS X handle this problem?
My other first post is car post.
For example:
Files: this is one thing Windows has right. There should be all sorts of capabilities built in to Unix: append-only files, append-only by user, unchangeable permissions, and so on. FreeBSD's flags are the way to go, but like I said: they should be built in to Unix, not an extra add-on.
And a subset of that is coarse permissions of files. Why in God's name do we still enforce root-only opening for ports built in to Unix, not an optional add on. Something like "chgrp www /dev/tcp/80; chmod 600 /dev/tcp/80", rather than having to open as root then drop privileges (hope you did that right!), would be amazing.
Carousel is a lie!
"Methinks you've got the PCL/Postscript design tradeoff backwards."
Methinks a lot of the "what's wrong with Unix?" answers will be useless, for the same reasons that "how do I get a woman?" answers would be.
Even if window$ $uck$ at least its easier to use a windows system than to use 'man foo' or 'bar --help' constantly at a unix shell. still kde and mandrake does make it a little better for a newbie to use unix (un-like cde/twm/*sh...etc)
Problem: fork() takes too long.
Solution: pre-allocate memory for page tables and program text/data, similarly to Apache's worker-thread model. Make it tunable: how much memory to keep wired-until-needed, how many page tables to pre-allocate, idle time required before new pre-allocations, etc.
Then watch how fast Apache, Oracle, and X launch.
I know, I'm not an OS designer. This is only gleaned from what I've read around the 'net. But if someone decides to try to implement this, I do ask that I be given credit.
Libraries/Dynamic linking..
About 30 years ago someone said "hmm, lets save disk and memory by having 1000's of different 'modules' that will be created by 1000's of different people and used in 1000's of different programs that will all share common functions.. what could go wrong?"
We live in a time where memory is cheap and network speed is fast, I'd rather run a 50MB program that just worked rather than a 500K program that took 4 hours of dependency and sub dependency fixing before it could work, Windows is a little better - people havn't really caught on to this whole dynamic thing so they just cram all the slightly out-of-date libraries in with the software or statically build it, and wadda you know? unless something has spectacularly screwed up, you never get a problem (its only when someone who _does_ understand dynamic libraries writes software that you get dll hell - take the GIMP and GAIM, both use GTK but they are always using different versions and Windows really doesnt like it. The whole thing needs a revamp and maybe it could actually work, but only if theres a seriously good library management system thats fool (and developer) proof and works every time...
This comment does not represent the views or opinions of the user.
I do believe there are a few problems with you assertions:
/proc/sys/fs/binfmt_misc/register ]; then /sbin/modprobe binfmt_misc /proc/sys/fs/binfmt_misc
/proc/sys/fs/binfmt_misc/register ]; then /proc/sys/fs/binfmt_misc/register ...
:)
"1) Make filenames and command flags case-insensitive. The few cycles you spend doing case comparisons will quickly pale in comparison to the time savings you experience in tech support situations where a touch typist accidentally hits space too soon and types "emacS.""
That problem is so much easier to fix than changing 20+ years of UNIX design.
UNIX is case sensitive for a reason. Do you think you can just go through all the source files, replace strcmp with strncasecmp, and have a system that works the way you want? No, you'd have to work things on multiple levels, regression test countless applications, etc. You could, for example, make internal shell commands case insensitive, but that's not the same thing.
Plus, by making the switches all case insensitive, you've suddenly halved the number of possible arguments for any program unless they use the GNU extension. POSIX args are 1 character only!
PS: "2) Several files that do not have extensions usually have some information about their default parser in line #1. Either parse it, or start using file extensions in *NIX."
This is done already. As long as the file is marked executable, the shell will properly lauch the parser. You can even add BINARY formats to the kernel. Check out this way to make all MONO programs run automagically:
if [ ! -e
mount -t binfmt_misc none
fi
if [ -e
echo ':CLR:M::MZ::/usr/local/bin/mono:' >
else
echo "No binfmt_misc support"
exit 1
fi
Honestly, most people who come up with "problems" in UNIX either fail to understand the reasons for certain design ideas, or aren't aware of pre-existing solutions to their problems. The init scripts and system startup sequence (in general) in UNIX is a much bigger problem, and one of the Gnome guys is making a great replacement for it.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
They spelled it creat(2).
Nothing.
Our little 400MHz linux boxes have been doing that for about 10 years now.
Welcome to the internet age, apple fan boys.
$ su
Password:
su: Authentication failure
Sorry.
$
'nuff said.
At least the war on the environment is going well
What Unix needs is a compiler (pick your favorite language) that generates code which prevents buffer overflows. Checking for buffer overflows should be a system function with application level override.
I don't have time to think about what's wrong with UNIX. I'm too busy writing perl scripts to work around the shortcomings.
Start Running Better Polls
Personally, I don't think there's really anything "wrong" with unix.
Now, if you asked me "What is wrong with Linux?" I would have several answers. Same with "What is wrong with FreeBSD?" so you don't think I'm just a BSD bigot. But "unix"? It's hard to pin anything on the generic term "unix".
The thing that is wrong with UNIX is the file system, or more specifically, a file system stuck in the 70's. Come on. File systems should be Databases, and I don't mean a database stuck on a file system. At it's core, it should just be a database removing this silly antiquated notion of directorys as the sole means of organizing data.
Every application should be able to create it's own schema for it's data needs.
Yeah! Where's my Google job offer!!!
I know this sounds totally mundane, but it drives
me nuts on a daily basis:
there's no real standard cut and paste when you're dealing with UNIX and GUI's.
I regularly use Solaris CDE, Linux Gnome, OS X and
(gag) Putty from Windose.
Lets see:
Is it ctrl-c, ctrl-insert, shift-insert, apple-c
or what ? And it's not even consistent within one
environment !
If you can't even do c&p consistently, how are
you ever going to get API's POSIX and all that
crap to work consistently.
Yep, amigas had delete attributes, along with script attributes and a few others that are missing on Unix.
The annoying thing is that they probably exist in Linux's extended attributes, but only Enlightenment 17 is doing anything to make them a desktop reality.
It sounds all computery. We should change it to Walter.
STOP. You're being farmed.
"Yeah, I know that most *nix lover simply love it. But let's face it : this language, which is still the most important one in a unix environment, is really aging."
Languages don't age. People do.
"It is possible to develop big software in pure C, but it takes much, much time, and the risk of introducing bugs and security flows is huge. Only the minimal low-level core of the system should be based on C ; the rest should be developed in a modern, high-level language."
Like Darwin and Objective C?
Since Unix is many things to many people, what is wrong for one may not be for another. One of the historical major problems of Unix, splintering, has largely been overcome. Today, Linux, *BSD, and Solaris are the big players, most other versions are end-of-life, unpopular (for /whatever/ reason), or redundant (the bad way, not the good). Code built for one flavor (if F/OSS) is mostly ported to every other flavor, only the commercial software is hit-or-miss whether you'll be able to compile/install natively on another flavor, but it would take being a top decisionmaker somewhere to change that. The technical capabilities of Unix are top-notch, and only getting better. The UI slowly but surely is improving from a low-level user point of view. Securing a Unix machine takes a high level of knowledge, but that holds true across any platform. Either you care enough about security to follow best practices and keep up to date on your patches, or you're a bad person. It's cut-and-dried. Standards are being proposed, discussed, and documented for everything, no complaints there. We could probably do with less feuding, but as long as there's different people, there's different viewpoints.
I applied to work at Microsoft. The interviewer asked me: "What's not broken with Windows?" "How would you break it?"
This is your sig. There are thousands more, but this one is yours.
erm... try joining the wheel group or setuid'ing su..
# chmod u+s `which su`
# ^D
login: root
Password:
# usermod -G wheel RyLaN
# ^D
logout
login: RyLaN
Password:
$ su
Password:
# _
root
Happily the board seems to be clear of moaning about the security risk of root. I mean let's be realistic. If anyone can actually get there hands on any sysadms password if said super user had more than three brain cells, then they could probobly comprimise the entire system anyway no matter what security measures were in place.
Occassionally people do fret, "Is root to powerful? Did we make it too powerful?" Root's nothing an NT domain controller isn't anyway, and they never complain about that. On top of that, what other solutions are there? Multiple system controllers responsible for various critical systems? If even one fails the system will. No. Somehow, someway, someday, someone will need all seeing all knowing access to the system. The kernel has it anyway, so realistically some human being should have access.
Seriously, we have chroot jails, 5 second password delays, random password generators etc. The unix chaps even introduced su which they would never have done if they considered root to much of a security risk. That said, needing such awesome capabilities just to install minor programs, libraries and plug and play devices might give justification to calls for greater grainularity. However, most sysadms are tyrants anyway, and would probobly revoke such privilages on sight!
root's not broken. Don't fix it.
May the Maths Be with you!
* NOT the filesystem organization. It indeed sucks mightily, but it's all convention that a sufficiently bold distro could change ... and become instantly despised and obscure for it, but it's still possible. It's a "softcoded" problem, if you will.
/proc is a disgusting hack to use in anything but scripts.
* All IPC except shared memory is mediated through the kernel, requiring several context switches. Signals are especially heinous, but it also made message queues, which would have been the answer to BeOS (before beos came around), practically useless.
* All I/O is synchronous. Combine this with the lack of decent threading. Linux made processes so cheap they could be used instead of threads, but never evolved the process APIs to include process subgroups -- hell, it still has zombies. Now it's given up and just copped the awful pthreads API instead.
* Way too many assumptions about simple numeric values, from errno to file modes, are coded right into the standards. This primitive interface becomes pretty much unextendable.
* No process metadata model. It's still possible to obscure the full command line for instance, even if you wanted to keep it.
* Absolutely no dynamic instrumentation model. I guess Solaris went and did their own thing, but I had this gripe for a long time.
I am no longer wasting my time with slashdot
I'm sure after seeing the responses that everyones given here, that the people at google were sorry they ever asked the question. I haven't seen a single post yet (not really surprised) that has said what is wrong with unix. About 75% of these responses are whats wrong with linux distributions, 15% have been whats wrong with the a specific kernel (usually linux), and 10% are trying to explain the question (I guess my response falls into that category).
So in response to your responses,
1) Linux and BSD are not unix, Linux (and everything written for linux) were originally written to emulate a unix system but now do even more, and BSD was a unix like system written alongside unix.
2) Saying whats wrong with a certain driver in any unix kernel doesn't answer whats wrong with unix as you don't need to use any specific drivers in order to be a unix system. All unix was originally was a portable multi-user, multi-processing system which was written at bell labs (in 1969 i believe). Now to brand your operating system unix, you must follow the 1170 Specs from The Open Group which states the system interface devices, the basic tool environment, networking services, and the X/Open Curses standard (non of these are any specific binary you need to install, just general rules to follow when creating each of these base systems).
I completely agree with the lack of an undelete option - no, the wastebasket on your desktop is not enough. There should be some sort of undelete option avaiable at kernel level - i once thought of moving files to ~/.trash (only browseable by owner), with a ~/.trash/.trashbin file stating their original path. The kernel then only needs to ensure that folder never exceeds a preset amount. The rest should be fairly easy.
At first I was inclined to agree with you. All the various files in /etc/ or in /sbin installed in many packages is a huge pain. I do think installation programs should be more uniform about using symlinks. So that all program files would truly be kept in /usr/???/progname/ and everything would be a symlink to this, preferably keeping the symlinks to applications and core system tools in differnt directories. Some programs follow the symlink philosophy but not enough.
Aside from this minor quible I think the extra 'complication' of the unix files is largely illusionary. All systems must store systemwide settings and data. Some OS's hide this information in a registry or other opaque data structure so you never see the clutter left behind by programs but it creates just as many if not more problems.
If you liked this thought maybe you would find my blog nice too:
Isn't it interesting that all of the answers given could simply have been fixed long ago, if AT&T simply had changed their licensing?
:P), AT&T kept such tight control on the UNIX license in the early days, that it allowed Microsoft to come in and scoop up all the marbles.
For those of you who didn't know (or weren't born yet
First, while they would give UNIX out to Universities, it came with the clause that it couldn't be used for commercial use. Secondly, if you were at such a University, AT&T would literally deny the existence of UNIX (even if you had a tape from AT&T). I remember one guy in the Computer Center who was complaining about this when he tried calling them about the V6/V7 software.
If this strikes you as odd, you have to remember that this was the time when AT&T was wrestling with the US Government about its monopoly control. AT&T absolutely didn't want UNIX counted amoung its assets if it was going to be broken up.
Then, to compound things, AT&T made it impossible for the companies which resold UNIX in the 80's to compete price-wise with DOS (and later the early versions of Windows). With typical reseller markups, there was just no way one could compete with the "free" licensing of DOS (free as in only to Microsoft). Consequently, AT&T completely blew the chance to dominate the PC market.
Even afterwards, AT&T can also take credit for putting many of the companies who were reselling UNIX out of business. For a while there, no one was paying their AT&T royalties. When AT&T caught on, companies either folded, or were aquired.
Even SCO wasn't immune. They weren't paying royalties to Microsoft to send to AT&T for Xenix. Consequently, Microsoft got stuck with having to pay AT&T directly; and in exchange, they ended up with 20% of SCO's stock.
Fortunately, some people decided to fix this licensing problem. Like RMS and Linus, and many, many others. And consequently, many of the main technical problems inherent in UNIX have been replaced by the solutions offered by Linux.
But one can only wonder what the world would be like if AT&T had adopted the GPL licensing scheme when RMS first announced the GPL.
Yeah, I know. That would've been too revolutionary. But if they had, AT&T UNIX might still be around.
Can't redirect streams after they've been created.
.
I want to run `command`, maybe interact with it, see that it's running, ctrl-Z suspend it, and then `bg > command.log`
`nice` for network and disk bandwidth
Imagine something like `netnice -5 httpd` or `disknice -10 postmaster` to make your web or database servers be more polite. You could give priority to your sshd and make sure you can always log in.
fix the termcap anarchy
Why is it that NN years after the invention of terminals we still can't get them all talking properly? Sure, you can pretty much always fall back on vt102, but still...
Start Running Better Polls
You can save old handlers.
We need a layer that sits between the shell and the applications, so that when an error happens it will catch it and attempt to give more information on what happened.
But not be as clunky on a system as a full time debug.
"Consider how lucky you are that life has been good to you so far. Alternatively, if life hasn't been good to you so far
SCOX is the acronym that the current SCO Group uses on the stock exchange.
SCOG is how the SCO Group is referred to on Groklaw. This is because there was a legitimate company whose initials were SCO. The people who currently call themselves SCO are trying to use that name to confuse people into thinking that they are the original organization.
In any event as I have pointed out elsewhere, these people are not the owners of unix.
... by a sysadmin to `increase' his security
What you mean like a .app Package for Mac OS X? Granted, things get a bit more bloated by pseudo-statically linking frameworks, but it has the effect of making installation and removal dead drop simple.
What if it is just turtles all the way down?
Nothing. Thats why it's the most stable design 40+ years running. To my knowledge it's only gotten better since then. Add on open source and free software. What the hell else do you want?
If something doesn't work you modify it and keep going. Unix or Unix-like systems are the most prolific and used systems in the world when it comes to no bullshit stable operations.
This isn't even a question. Google itself is an example of what Unix-like systems are capable of. Whats to change?
It would be great if we could get some general standards for object passing and calling. Be it COM CORBA or whatever it shouldn't depend on what widget set someone wants to run in their window manager. In fact programs should be able to rely on this even if no GUI is running.
I think the unix world needs to settle on a universal object model and implement it either in the kernel itself or in a low level driver.
If you liked this thought maybe you would find my blog nice too:
I don't know all that much about either of these. I have been playing with Linux for the past several months, and there are several things that are "wrong" with it...
Not that I would say it is "wrong" but more or less, "inadequate".
Ease of Use. Ease of Install.
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
Where does this crap come from? Appple marketing?
You clearly haven't used OS X
Open standards are being embraced just about everywhere you turn in OS X
Like DRM in Ipod?
Like quicktime codecs?
Does the phrase "just about" mean anything to you? We have Darwin (the kernel plus more), the compiler used in XCode is gcc, it includes tons of examples, and some of them are even programs included with OS X. Many developers for OS X open source. Just because Apple hasn't open sourced everything, such as the parts of OS X like Quartz, Aqua, etc that help bring in a profit so it can't be copied exactly, means they care about money which every company does.
The numbers of Macs involved in secure and classified work in the Federal government have been exploding
Exploding computers?
Don't be a smart ass
The file i/o abstraction used for everything used to make sense, since just about everything used to make sense as a file. Disks, etc. are fine. Soundcards and USB mice don't make any sense as a file. Overreliance on this abstraction causes a lot of weird counterintuitive interactions with the machine. To set up my mouse I have to do something with /dev/foo/bar/where/did/it/go/ahh/there/it/is/mouse , and that's only if my distro has been kind enough to symlink /dev/whatever/mouse to whatever the mouse *actually* is.
or maybe I've got to echo a 1 into /proc/where/is/that/thingie instead of updating a configuration file. Or maybe I've got to do both?
I could be wrong, but that's just my view from /dev/chair/user/ktwombley
There's one elegant thing in VMS that I'd like to see come to Unice and her friends, the Asynchronous System Trap (AST). This event occurs at the completion of any system service. Many VMS kernel calls, especially those that do I/O, timers, etc are reactive like modern OO frameworks. When the service completes, the kernel delivers an event to the procedure supplied with the service request. The caller supplies a callback and a parameter to a C style procedure. The parameter can be an object pointer. The callback can do object->onEvent(). The kernel does all the book-keeping on a per request basis.
Blocking services block in the library. The library service wrapper hibernates until the AST wakes the process. The library fields the AST internally and returns to the caller at the next instruction. The kernel is inheirently no-wait and services come in one implementation with wait and no-wait wrappers.
Slick. As nice as logical name translation is evil.
You need to poke into places where only root can go now, when doing a security audit of a Unix system. Root is the worst choice in the world for security auditing. Unix needs a special user who can visit any file that root can, but whose ability to change things is sharply restricted. The root cause is simple. Unix' basic design dates from a time when nobody, but nobody, thought of security as a real issue.
As far as things I'd like to see improved - at a job a while ago, I had to use an IBM mainframe (OS/390, I think), and while overall I found it pukeable, one thing I did really like was the fact that you could log on later and review the exit status of any of your jobs. (Which makes perfect sense for a batch-oriented system.) In Unix, if you don't immediately check $?, you've lost the exit status of your jobs. Shell history only captures what you entered, and only from the shell itself. As a system administrator, I'm often running things in the background, via screen, on multiple systems, from cron, etc., and it would be nice to be able to be able to check on everything that's run. There is auditing, but that's usually a real pain to set up.
I'm a little surprised that no one has mentioned (as far as I've noticed) ESR's The Art of Unix Programming, which has a section titled "Problems in the Design of Unix". From that book:
So you replace a tape model with a disk model?
Why not switch to a more abstract approach, where the OS actually has some concept of the data it's moving, and can therefore deal with it in the most efficient way? Why not have each computation resource and media resource multiplexed and used maximally?
For me, an ideal system would understand as much of what I'm doing as possible: I'm not writing bytes to a file, but re-encoding a raw RGB video as a compressed, tokenised version of that video. It involves streams of colors and sounds, and digital signals. So naturally the DSP resource from the sound card will be helping to process it (along with whatever other uses the system is putting it to); the blitter and color conversion engines on the graphics card will be needed, and all of the graphics will be operated upon in video card memory, since the system knows that video sequences are best suited to and normally allocated there.
All of this is a background job, not crucial to my next mouse click, so obviously it should be on a queue of background tasks -- the same queue, shown in a progress bar at the bottom of my screen, where all other background tasks are queued, no matter what application they come from. When I ask for something to be done, it either happens immediately, or gets queued and done in the background. When something happening in the background interferes with my ability to receive input from the screen, or my ability to control the machine, that's a serious OS fault.
http://www.dreamsongs.com/WorseIsBetter.html
Dyslexics have more fnu.
I know this is likely part of the question, but define unix, and what we CAN solve by fixing "unix"?
.... standpoint?
Does unix include all of the programs as well, or only the posix specification and other bits and pieces?
Is this from a system administration, a "complete os", a end user, a server, a
Then again, maybe that IS the answer to the question. The problem with unix is "what IS unix?"
I mean, hell, dictionary.com has it as http://dictionary.reference.com/search?q=unix " A trademark used for a computer disk operating system.". It also has the fact that it's a multiuser timesharing OS, but MANY os's do that, so if the only thing defining an OS as unix is that it's timesharing and multiuser, then windows XP is unix!!
Anyways, if I had to answer, I'd say the biggest problem with unix is that, due to its roots in academia, there is way too much NIH syndrome. Every unix has a different way of managing packages, different slight idioms around file system layout, etc. Stuff that DOES NOT matter to the end running of the system, but is different for no good reason.
Choosing a unix should be about choosing a platform (hardware/etc), which kernel and userland you trust/want, and so-on. Where the default home directories are stored should not even come into it.
I just made a big Linux commitment - I have a new system and an old system - the new one (bought in 1999) was running Windows 98, the old one (bought in 1996) was running Debian. I had a ton of trouble getting my Linksys USB 802.11b wireless adapter to work with Windows 98, but it worked fine on the old system. Also, I had these stupid "Compaq Windows 98 recovery" CD's which were horrible as they wiped my C (which I expected) and D (which I didn't expect) drive when I tried to reinstall my Windows network junk. I said screw it, I installed Debian on the C drive, and got my phone number list from the D drive as a device (grep number /dev/whatever, cat /dev/whatever |strings > file), then re-installed Debian. So now I have Debian on both systems.
I have things working good - I got my network card running, my Linksys USB 802.11b running (actually easier with Linux than Windows), my soundcard working and I used MPlayer to watch some AVI's, MOV's, WMV's and MPG's, and xmms to listen to some mp3's.
The one serious thing I think about is being able to read and especially write Microsoft Word documents, especially to write a Microsoft Word resume and send it somewhere. I can do that in Linux though, of course, and even if I had a problem I have access to Windows machines. Another thing I think about is video format - will I be able to read the latest AVI's, MOV's and so forth? That's not as important as beign able to write a Word document (resume) though. Which is possible in Linux anyhow.
The other major thing is games - Warcraft, Diablo, Doom, Age of Empires and what have you. X-Box, Playstation, Gamecube all compete with the "PC" (meaning Windows in this case), not Linux. I think this is a bigger issue. Microsoft trying to lock people into incompatible Microsoft Word documents, video formats and so forth is one thing, completely dominating on the games front is another - that is really a lack of function in GNU/Linux, not something resulting from Microsoft's desktop monopoly.
Now that I have made a commitment to Linux on my main desktop, which has a decent graphics and sound card, I'm going to check out some of the Linux games that are out there. I'm not even an expert on how far Linux has to go - even if Linux had an equal to ActiveX, is it on enough desktops with enough customers so that doing an Everquest for Linux would be worth it? All I know is that with some exceptions, major game companies don't release their games on Linux.
The solution of course is to help it along myself. The problem is my C/C++ programming is OK, but not that great, besides which I have other time commitments. Oh well, Xboard chess works for me, so that will keep me happy for now.
An OS manages how processes share the resources of the underlying hardware. However, the process resources an OS manages seem to be frozen in timesharing days -- namely, the CPU % and the main memory footprint.
So, it is possible for a process to use a small amount of CPU, but wreak havoc by thrashing the cache. Or by monopolizing main memory I/O bandwidth. Or by causing massive amounts of VM paging. Or by saturating an Ethernet port.
It may seem unfair to lay this complaint at the doorstep of the OS community and not the architecture community, since hardware support is needed to let the OS manage these resources. But in practice, hardware features of this sort are added at the request of the OS team, and UNIX tends to ask for leading-edge things first. So I blame UNIX, because it hasn't asked :-)
There should be a way to have root shed its powers. As matters stand now root can do everything: print management, filesystem management, view users files, organize groups, maintain system logs etc...
Cracking root makes you master of the universe as matters stand today.
Maybe root might start with all the powers at install time and then hand the powers (irrevocably of course) to other people.
The only thing that I have cared about in any operating systems is that the drivers work. Back when I used windows I had problems all the time even getting the simplest devices to do what I wanted them to. I use linux now becasue of the dynamic module system, and the wide variety of supported hardware. Also since its all open source, I can write my own, or modify existing ones if my devices don't work right.
Even though I am now comfortable with the way the linux kernel works, I would totally start messing with BSD or any other open source operating systems if someone could properly reverse engineer modern video cards. Many people dont seem to realize this, but all of that pretty stuff in OSX doesnt use up any CPU or ram, because increasingly many the affects are done of the card.
I realize that x.org itself has leaps and bounds to go before it can even take advantage of hardware accelerated opengl calls, but getting better hardware acceleration support should be top priority for open source operating systems right now.
One of the nicest features of Windows is the standardised use of COM throughout. Everything about the shell is done through COM, which allows progams to work in a consistant and predicatable manner. Cut'n'paste, shell extensions, drag and drop. namespace handlers, OLE embedding, scripting, automation etc is all possible and well supported by most programs because of this use of COM.
Unix may have some form of COM, but it is far from the kind of support that is available under Windows. It is the reason clipboard and document embedding is such a pain under Unix, and why the shell 'feels' clunky and basic operations such as drag and drop between applications isn't possible.
So bring in a standard COM system, and standardise the shell interfaces and you will have kde and gnome applications that can integrate with the shell without having to have separate progams.
I.O.U One Sig.
kernel: The semantics of setuid class of calls is very confusing. Worse, it varies from from one flavour of Unix to another.
Look at David Wagner's "Setuid Demystified" paper The graphs in pages 9, 10 and 11 are scary.
user level programs:
I use Microsoft Windows sometimes and I find the "system restore" to be a nice feature. It is just convenient to press a button than worry about depdencies when you screwed up etc. Especially useful is you are sending a laptop to your computer illiterate mother in India and expect that she is probably going to try and install some random programs. If something goes wrong, I can ask her to turn the clock back, sitting in the other side of the world.
Sudhakar
I'd really like to get both the STDOUT and STDERR of programs I fork under perl, but everybody says it can't be done in practice because of unix deadlocks.
There ought to be a way to do that.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Postscript, PCL, dot matrix printers codes, those are not part of UNIX, they are printer language specifications and like in Windows, they should be provided by the respective manufacturers.
Then the very efficient UNIX printing spooling software will be configured to use the correct filter for the correct printer.
IANAL but write like a drunk one.
No discussion about the flaws of Unix is complete without a reference to the Unix Haters Handbook. (Ignore the URL - Microsoft had nothing to do with it) It might be getting a bit dated, but some of the points are still relevant, and it is very very funny.
A simple command builder GUI with check boxes to toggle switches and fields to enter args for a particular command.
- Select a command or executable from a drop down list and start clicking switches and supplying args.
- Paste the result in a command window or execute from the GUI.
- Save the command for reuse later.
A newbie could learn faster, veterans could save a little time. Educational, useful, possible.This is so moot in the greater scheme of things but..
... and OS X.
This might be specifically X, but I've noticed it in Gnome, KDE
The mouse just tracks wierd, I can't explain it more than that but it feels off for some reason. In Mac OS 9 or below, and windows especially NT level, the mouse seems to track "correctly".
In todays world making something case-insensitive is just not possible - you don't want that some names are the same in one locale and different in the other, but that is exactly how case-sensitivity works. ;)
Or if you insist, start using *NIX in some locale without separate upper/lower case (japanese/georgian/armenian/etc.) - as ASCII characters fall outside characters that shold be defined in that locale A and a should be separate "signs" and not something having a "case" at all - so here you have your case-insensitive *NIX
...most particularly, by ioctls. Everywhere else (almost), a userspace program can do anything a kernel module can do; ioctls, however, ensure that you can *never* have a userspace program sitting behind /dev/foo in place of the "foo" kernel module.
There are some other places where Plan 9 fixed up Unix's warts, but IMHO this is one of the bigger ones. Encouraging folks to write kernelspace drivers is just icky.
Those are the manuals that come with your OS.
man pages are more like memory aids for the experienced user, they were never meant to replace the full manuals for the OS.
Solaris, IRIX, HPUX, commercial versions of Linux all come with thick volumes of clear documentation. For other OSes like BSDs or other Linuxes there is plenty uf free and commercial documentation available.
IANAL but write like a drunk one.
Plan9 has some nice things, like the ability to configure the namespace individually for each process, which allows to do things like having a single /bin directory, which is really composed of several directories (there's not $PATH environment variable in plan9)
Plus the ability to put a service behind a file and export it anywhere, like the windowing system does: instead of having a "network oriented" X11 protocol, plan9's windowing system (8 1/2) gives you a file (/dev/bltsomething) which represents your window, then you can export that file anywhere (thanks to the 9P protocol) and write to that file remotely. Instead of building a "networked protocol" like X11 is, in plan9 is the system who is network oriented, not the apps. That's my biggest complain of unix: it's no really network oriented, even if it routes most of the internet traffic
Take spell checking as an example, but this applies to many many tasks a computer can easily perform. My word processor includes a spell checker. If I don't know the spelling of a word, I can right click on a close approximation and likely find the proper spelling. My text editor does not include a spell checker, but it includes commands to run a buffer through external programs (e.g. ispell). If I don't know the spelling of a word, I can send part of the buffer to the spell checker. My shell does not have a spell checker. If I don't know the spelling of a word, I can run "dict approximation" and hope for the best, or "cat /usr/share/dict/words | grep". My web browser does not have a spell checker. If I don't know the spelling of a word, I simply misspell it and take the ridicule from the slashdot horde; alternatively, I open a shell or use the word processor to do it and copy the correctly spelled word back to the browser.
In my opinion, I should not need to care whether each and every application requiring text entry can or cannot spellcheck, and if so whether or not it will use a certain spell checker with features I've come to enjoy (a personal dictionary for example). I should only need to care if "the computer knows how to spell check". It does, does it? Ok, show me how. Ok, now I know how to spell check every bit of text I could ever want to. And it's always the same.
UNIX expects all I/O and interprocess communication to occur as serial streams between devices and processes. This is highly limiting when dealing with responding to large numbers of real time events in an asynchronous and parallel universe. For large scale data acquisition or robotics I/O it's a serious problem. Real-time kernel hacks notwithstanding, it's the user libs which need severe restructuring to overcome this flaw. In which case you're not running 'NIX, but some very specialized application with kernel hooks for event handling.
A completely new OS design with more than a simple multi-cpu thread model and real time hooks are what's needed. How that would look internally is anybody's guess. It sure as hell won't be Windows though. Plan 9 had some really neat ideas. So does SmallTalk and the whole 1980's LISP systems movement. If I had to guess, a new real-time data acquisition/response programming platform would integrate some kind of functional programming compiler/interface with a real-time kernel. NOTE that I AM talking out my ass here...
What matters to me is that there is some semblance of CONSISTENCY. That is why I hope more attention is paid to FHS and LSB. Package managers can do the housekeeping--I don't care--but Fedora and Mandrake and SuSE and many others use RPM and their packages are STILL specific to their distros (even though Mandrake started as a supposedly Red Hat compatible distro way back when). I really wish RPMs at the application level were LSB compliant so they'd play nicely.
/usr/myapp/1.0/bin/startmyapp instead of startmyapp at the prompt is annoying.
.dll and other files in C:\WINNT, C:\SYSTEM32 etc etc. The "install with a single xcopy command" nirvana only exists in the dreams of .NET fanboys (it might be possible technically it won't and can't happen for a couple years yet).
On another note, there are reasons why apps on UNIX become installed in shared directories--it is because path management can become tedious--the PATH environment var becomes too long, or else you have to sprinkle links about your filesystem. In the GUI world this isn't really an issue, but some of us still like the command line and write scripts and typing
BTW, it seems you have MS Windows confused with the Mac (the only modern PC platform I know of where the "copy a folder" install method is still commonplace). Win apps most certainly do NOT install in a single directory--nearly all use the central, monolithic, non-human-readable REGISTRY to store configurations, and typically throw
I'm not speaking of unix specifically, but of Linux. But I hope this enlightens anyone.
./configure-make-make install and recompilation pain, etc etc etc.
Linux isn't friendly for:
* Installing apps
* Guiding the Joe user to a friendly painless installation of the OS itself
* customizing
* configuring
in other words... everything.
As many linux fans that there are here, the only *great* thing that Linux has, is its security and stability. Everything else is more or less, a mess. The apps, they're great! But only AFTER you manage to intall and configure them.
And on the other side, we have a wonderful MS Windows in which everything (BUT security and stability) is great, but security and stability is a mess. I admit it, Linux infrastructure is very well thought... but the rest? The problem is that Linux (or unix for that matter) was made "by nerds, for nerds". Windows was made "by executives, for Joe users". What we need is an OS made "by nerds, for Joe users".
And that means not rejecting as "blasphemy" everything that MS Windows has. There are many good points in windows, but (i'm generalizing, but this is my impression) linuxers are too busy defending their "way of life" against the competition, that they can't improve it. They have formed themselves a mindset saying "Linux is perfect. We don't need no stinking windows thingies. Anyone who says so has been too much in contact with the evil windows, and must be deprogrammed". If someone dares say "but..." he's just rejected as some microsoft borg slave.
And they've repeated this lie so many times that they've ended up believing it. They make this whole bunch of "user-friendliness" *patches* for Linux, so they can believe that it's good the way it is.
Well, guess what. It isn't. Give me a Linux with the user-friendliness of windows (and I DON'T mean the GUI - i mean the versatility, plug-n-play, ability to easily install new apps without the
What I mean is:
Linux (as a whole) is a good set of implementations. What it needs is a good set of standards, and ONLY THEN, develop good implementations of these.
Want an example? We have KDE, QT (is that spelled right?), and I forgot if there was any other.
So there are apps compatible with QT that can't run on KDE, and viceversa.
Maybe you guys haven't still seen the big picture, but what I see of Linux development is more or less this:
a) Some guy makes a good thingy for Linux.
b) Many guys follow him
c) Another guy makes another good thingy that does the same than the first one, but it's incompatible.
d) Many guys follow him.
e) GOTO a)
From a religious perspective, compare with Roman Catholicism and protestantism. Roman Catholicism would be Windows (one pope called Bill Gates who dictates what is true and what isn't) and Linux would be the protestant denominations incompatible with each other. Some survive, some die... etc.
Sociologically, protestant denominations are very similar to Linux implementations. They share one very limited creed (the Bible / the Linux Kernel), but how that applies in their lives (the implementations) vary. SO MUCH that they can't be united (I remember the SCUMMVM team - or was it another? - splitting because a guy liked one editor, and the other guy liked another editor. And they argued so much about this that the whole dev team dissolved.
Linux needs a "pope". Or a government council (like the W3C) which says which way apps will interact with each other, with the kernel, and with the hardware.
Let me rephrase it: Linux needs STANDARDS. Linux needs something like "a W3C" government which publishes a standard, uniformed API of doing things. Like what the w3c did with the DOM (and so we can prevent things like the "browser wars" happening in Linux.
One of the reasons WinXP flourished is that it had a standard way of doing things. Make them compatible with the API (even if its security is as solid as a gruyere cheese), and they r
On most servers the user interface doesn't matter whether its text based or a GUI. But for the average Joe who has trouble using windows how do you expect them to use *nix. Development tools are the future. If its easier to develop a GUI application in windows using VS studio how is *nix going to compete. Until that happens forget about trying to improve it. I Understand that there are tools to build GUI's like Kylix but doesn't use the gcc compiler which everything is compiled against. Then theres QT another nightmare. Then there is Mono which could be the answer to .net.
But you still need a GUI development tool to beable to design GUIs, write code, complie, debug and run from one application.
OK, you know about Darwin, but if you go to the Apple site you can look at the code for WebCore, OpenDirectory, Apple's Kerberos implementation, Darwin Streaming Server, Apple's drivers for their hardware, their mods to CUPS, Samba, ZeroConf, GCC, Apache, and a whole SLEW of other stuff.
The only stuff they don't give you is the source code to Aqua and their in-aqua userland apps, which makes sense, because giving that stuff away would be business suicide.
When Apple said they were going 'open source' it didn't say they were going to release the source to their core apps, like the Finder and iPhoto, but they've been very generous about contributing the code they borrowed and modified back to the community.
It should also be noted that Apple gives back to the projects they work on, GCC has come quite a way on the PowerPC since 3.0 thanks to Apple.
In my opinion, Apple's strategy is one I'd like to see some vendor take with Linux, you take the kernel and mod it for high-performance desktop apps, get GTK+ running on an accelerated OpenGL framebuffer, tweak and simplify a slew of apps and SELL it. As long as the mods to existing software make it back to the community, it's a net gain for all of us.
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
Tons more, mostly it is just a problem of cruft and people trying to deal with every standard org that ever decided to publish the One True Unix standard making their standard just different enough to be a PITA.
[Set Cain on fire and steal his lute.]
The filesystem abstraction is good: You have a lump of data, and any process can stream it in by asking for it by name.
...) in more ways than just pipes.
But we are stuck with the idea that only kernel-kackers know where the data comes from. Even things link Linux' VFS require kernel modules to add new filesystems. So user-mode users can't add new types of files.
Why is this important? There are several types of problems that could be easily solved using simple user-mode mount points:
1) persentation of information: Lets say we have a set of objects (or database rows -- the data source shouldn;t matter), and you want to present it as a file. The unix-way is to run a query to generate a file. The you can look at the data in a n editor; and if you modify it, you can run an update script to put the data back. So we have 2 operations to "open" the data, and 2 to update it. Why?
A kluge solution would be to attach trigers to the open/close file operations, but that doesn't really work. I want to be able to type:
ls people.age
vi people.age/20-24
{edit and save}
and have it all work dynamically (i.e. I'd be able to use standard unix tools to browse data, and modify it).
Non of this is rocket science. People talk about database file systems, but they're looking at the wrong part of the problem. Anyone with root access can easily (well moderately so) write a kernel module that does this today. But why isn't it user-mode?
A second usermode filesystem app should be version control. It should be possible to write a filesystem client similar to Clearcase without being a kernel hacker.
I remember I once asked on Perlmonks about a tool called PerlFS, that lets you write filesystems in usermode (though you do need to install a kernel-module to set it up). I was laughed off the site -- there is a mindset that says "filesystems are kernel apps". "It'd be too slow" people say, forgetting that you can mount (and use) NFS over a 14K modem. "It'd be insecure" is another favorite.
People build IDE tools for developing software, but they forget that Unix *is* and IDE. We just need a filesystem that lets us join together the fundamental tools (ls, more, grep,
.
Opinions my own, statements of fact may contain errors
Trash. I can hack it into typical command line rm type usage. Even intervene in the clearing of i-node's through any program's call. Delete through Samba and it goes to the .recycle directory for that tree.
:)
I miss Netware's implementation where a deleted file is basically marked as such and placed in queue to actually be removed. As more space is needed or more files deleted it is moved up in the queue to actually be removed or until the specified timeout period has passed.
Watching a 100 users beat up a properly set up Novell Netware server and knowing nothing is going to easily be deleted (and easily be salvagable) is a God-send. Elevator seeking anyone? Watching 20 users choke a Windows server on the *same* hardware was comedy in motion. Linux can easily handle the "Netware" load, but...
Of course those really interested are watching Suse very closely. I know I am.
Everyone knows, the basic idea was "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features." and then make those little programs compatible so they can work together in any number of meaningful ways.
Only, that's not how it all turned out, is it? First, The Philosophy mainly applies to text-messages in the command line environment. Most of the tools don't really produce output that can be readily reused as input for others. That's because Unix tools use the same bastardized text output both for human readers as well as a datasource for other tools.
It works amazingly well, though, but it could be better. Ideally, those tools were objects that adhere to some basic (very very simple) interface standards. They could interchange machine-meaningful object and property data which could be rendered in any number of ways as needed for the end user.
Also, The Philosophy was misapplied when desktop environments were created. They're horrible and bloated and not really that modular. Besides, I expected some radical new GUI features to be invented in accordance with The Philosophy. But all that actually happened on the desktop was a (mostly bad) copy of Windows.
But otherwise, it's great!
Need a Python, C++, Unix, Linux develop
thats the one thing wrong with Unix...
...who don't want to exert even the slightest effort to reap the benefits of a truly powerful OS are a problem.
~
~
The purity of the data / processor partnership has been lost as the amount of data we rely upon for daily computer use increases. Memory used to be all there was, with hard drives or other storage media being treated more like accessories than integral parts of the system. But now treating long-term storage so differently from RAM interferes with abstraction. Refences to data are unstable because the data are serialized in some ad-hoc fashion between program executions, so a large amount of potentially useful information remains locked away in the file system. The OS needs to provide a richer foundation than simple address spaces, instead supporting data structures in a manner similar to a Lisp top-level and automating their persistence to disk in a standardized manner. This way, once data was created once it could always be reached in the same way... a sort of "stability of data reference".
Setuid binaries are the things I hate most. There needs to be a concerted effort to eliminate them where possible. The most notable examples where they seem to be needed are for changing passwords and programs that need to access TCP/IP ports below 1024. I would suggest two fixes be considered:
/dev, with ownership of those devices being assigned to programs that need them. For example, /dev/tcp/ip/80 could be owned by user www and /dev/tcp/ip/25 could be owned by user Sendmail.
1. Split the passwd file into multiple files, each owned solely by the user it represents. That way, the passwd and chsh programs can operate without being setuid.
2. TCP/IP ports should be represented in as devices in
Of course, there are probably many technical reasons that this wouldn't work but that is my suggestion.
I would also like to see more of an effort to get people to appreciate the culture and beauty of Unix. It pains me everytime I see someone talk about Linux and the BSDs solely as a means of knocking off Microsoft. I don't use Unix because it isn't controlled by Microsoft or because it is free. I use it because I think it is better.
The main problem I see with my preferred brand of Unix on the desktop is I have to run it on a Mac to get the pretty widgets/gadgets.
.app bundles are cool. code/library/config/resources scattered all over the hard drive is not..
Give me OS X/ X86 or I'm gonna club this here baby seal!
Not having to muck around with getting X11 is cool. Hats off to folks like Knoppix who manage to make a setup that works out of the box with most systems..
Printing.. Printing needs to get sorted out a bit better. Too many people have problems printing or find themselves buying a postscript printer just to have it work somewhat well.
Configuration: Preference panels to hande configuration are nice. editing config files with vi/emacs/joe/etc is not all that nice. It's nice to be able to do either, though..
I honestly don't really care how it all works underneath, just that it does.
Simple UI's.. So many group are making desktop environmentst that look like and work like windows.
Simple is good. Windows UI is only simple because you use it for years..
Man feels like function documentation by the programmer for the programmer- or for really advanced users who already Know the system as it existed during the devlopment of the application.
Man is not a Guide.
As a n00b, I'd love to be able to type, say.... guide vim and get a guide to using vim for the new user. Not the results of man vim, which is the vim man pages the way the vim programmer(s) decided they should be organized.
long live Linux!
thats a fact, proven not least by the drovs of companies that has replaced expensive UNIX iron with cheap Linux x86-based hardware servers and workstations.
Whats wrong with UNIX? its a dead horse that only some oldtimers continue to beat.
C is a sleek and powerful tool. To get the best out of it, you have to be willing to sit and learn. It's not for quick-hack programming, but for low-level code where size and speed are everything. It's the tool of the master-craftsmen. C 'strings' are a two-edged sword, the conscious descision to not bound check is that of an uber programmer. It's efficient and simple - the hallmark of good coding. However you must be exacting in your code, that's the price. If you put in the effort to get it right, you are justly rewarded. String bound-checking is a collar leading to imprecise programming.
Actually the BSD's are Unix-variants. Per the FreeBSD homepage, "It is derived from BSD, the version of UNIX® developed at the University of California, Berkeley."
The views expressed are mine own and do not express the views of my employer.
This guy shouldn't have not got any offers, this type of thing should be a 5 minute no-brainer: http://groups.google.ca/groups?selm=401c960d%240%2 429131%24afc38c87%40news.optusnet.com.au&output=gp lain
Penis Drize
I wish that a standard installer was built into the kernel so that Linus would through delegation would be in charge of it. Good package management that was consistant across distributions (because they would all use this uber-kernel) would be the nicest thing I could think of for improving *nix.
Shh.
isn't system restore for device drivers only?
The features your looking for would be found in ghost in windows or dd in unix
1) Older System V IPC sans pipes. Shared memory is the only one left that is really valid and it can stink to use,because of...
2) Yecchhh..semaphores.
3) Older central authentication and network file systems. Read NIS, NIS+, NFS and unadorned Kerberos.
Why not make this mess transparent and integrate
it into some coherent acl'd network filesystem,
with a set of easily configurable authentication apis or 'modules' speaking of which..
4) Yecchhh, PAM.
My last complaint with unix is the big one.
The X api. The API's to X and graphical apps
are really, really painful. No wonder Java
is used there.
gobolinux is a linux distro with the solution to the above mentioned problem.
It simplifies package installtion and management by redefining the entire filesystem hierarchy.
As mentioned on their site:
In GoboLinux you don't need a package manager because the filesystem is the package manager
~Aha~
I'd rather like to see (and have done some trivial work on creating) a system where the entirity of each application program/suite/whatever is put in a separate directory all under a particular root (like /opt). At each start-up a "runtime composer" goes in a stats the root. If it has been updated since the composition flag file, then the composer gives a real run at building the system directories out of the application suite directories.
/etc was godhead.
/tmp, /proc, /sys, /dev and /dev/hd??) you should be able to compose a complete environment very fast.
/etc directory." /etc is the Achilles Heel of every *NIX system.
The tricky part is to have a dependency language or something, so that the startup ordering and run-level preferences can be figured out. Its not insurmountable but it is non-trivial.
So anyway, packages that don't have all the requsite dependencies installed are "factored out" and a new bin and lib and etc directory is built out with simlinks and such. (Basically remove *all* the symlinks from the composed directory that don't point to things in the composed config, then add the missing links, which is a completely functional set-theory operation.)
Anyway, you get the "better parts" of an installer scheme with a "remove that directory" uninstall semantic. Installations are just an "un-tar and reboot".
One of the features that could be included are searching removable media (thumb drives) for packages that are to factor in to the currently composed runtime. Conser things like a read-only drive with the core system and the thumb-drive inclusion so that people (think students at school and cyber-cafes) with their own personality media could reuse interchangable core systems.
The big problems I see are:
Whining from the "must boot faster" crowd.
Whining from the "shouldn't have to reboot to install" crowd.
Needing a well designed dependency language and parser.
The security model needs some tweaking in general to allow for non-priviliged packages to be used in non-priviliged ways.
The system is fairly simple once you get away from thinking that UNIX's usage of
The actual ideal is to have the root file system be a tmpfs (etc) where you would build the core directory structure at each boot. Using "mount --bind", symlinks, and a tiny semantic initialization block (e.g. to make
You could even pass kernel version, boot media and/or a few other things (like invocation parameters and language choice) into the composer script to potentially have a completely different effective root for any number of variant purposes. For instance a kernel developer could have a root template for "normal use" and for "testing the new build" on the same machine. Generic constructs like --no-packagename would exclude particular packages at boot time. That sort of thing.
Basically we need to "throw off the opressive chains of having one statically preconfigured
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Most of the good free and good things is nothing special of OSX, What has Apple done that is now free? yes, some programs, but none that I use. Most of the open stuff in OSX is Mach, BSD or GNU.
So why should I use OSX, because it runs *Microsoft* office, and other non free software!
I feel fine running BSD and Linux, if I wanted to
run propertary software I would use Windows.
Dude, don't go dissing the llama. :-|
:P
I agree with the issues you state re: "installers", and in my experience, there simply is no easy way to remove a piece of software that messily sprays itself all over the file system. Try doing a manual uninstall of earlier versions of netatalk- it's like cleaning up after a two year old has had radio shack to himself for an afternoon!
The problem, ultimately, is that regardless of the system, the system will attract developers that are complete assholes. My favorite example is Adobe- they're complete fucking shits on OS X- so messy and disgusting you'd swear they were being intentionally malicious- an "installer" that shits files all over the filesystem and calls home during the install process- nevermind their complete failure to adhere to OS X human user interface conventions.
In reality, Apache is a bunch of variables and paths, SSH is a bunch of switches (YES|NO), and the config files for irssi and blackbox look like uncompiled C. Complete with the goddamned {curlybrackets}.
It doesn't make much sense for Apache to adhere to the same configuration method as SSH, and it makes no sense for either to be configured like a windowmanager.
Regardless of the formatting of the text config files, some degree of standardization could be slammed on with a decent system "control panel" a la Windows and OS X... but there isn't a single one out there for any *nix desktop that's intelligent and all-inclusive.
xrw flags are to limited. Should have a fuckup flag as well.
You see, I miss the ability to give certain users permission to fuck up certain stuff, without them beeing r00ts.
KDE does something like this, it uses a central dictionary to spell check in all text areas, with the red underline clueing people in to their failings.
But in general I think your point is valid. User interfaces suck.
I was thinking of a similar issue with the trend to "indexing", ala Google's new desktop offering (and everyone elses "me too" offering).
Universally these are done badly, and they are done badly because they are extras, if someone had though of this from day one (and had resources to do it - real time spell check on a PDP7?) all apps would have the appropriate search hooks (not just IMAP4). For the same reason apps not designed for KDE may not do that spellcheck thing as well.
In principal full OO design might help address this, if only we hadn't started here, problem, but only if we started with the right set of objects, and everyone built with them.
Realistically I think it just reveals how hard good software is to write, and I don't have easy answers on that one.
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.
Do you even have a clue what you're talking about?
:-)
What do you mean by a "pluggable API-level interface"? Explain how one "plugs into" one of these.
What do you mean by not depending on a single environment? Especially when you give "init" as an example of such an environment?
You can probably tell I've tutored first year CompSci students before
Pretend that something especially witty is here. Thanks.
It's actually WORSE in the linux community than it is in, say, the IRIX, Solaris or HP/UX camps. Then there's the OS X and Classic MacOS camps, which take the "being an elitist prick" mentality to a whole new level.
Oh, and there's LISP users and HURD developers. Dear fucking gods, they set the standard.
It is still a niche species, mostly restricted to server rooms, requiring specialized resources, and is clearly not preferred by "normal" end users, lets call them... Alice and Bob.
There are many reasons for this, many clever debates and holy wars. You can argue with every word in my statement, but is that worth anything?. Lets skip all that for once as irrelevant and ducking the real issue at hand.
I suspect its a side effect, a blind spot, because we are code builders. Anyone deep enough to build code can no longer see the installation use case. For most of us, installation is easy, even fun. There is no fear. its who we are and what we do. We easily forget that this is not so for Alice and Bob. This stuff scares them, because..., well for many reasons... who knows?, thats not our business, lets just accept that it does.
Marketing and Sales folks understand that this a barrier for Alice and Bob. Certain OS's and Apps focussed on that, and there, it has clearly been acceptably solved, at least as needed by Alice and Bob.
I understand and agree with most of the unix design philosophy. However, we seem to have leaked parts of that design intent, (especially the bit separating policy from mechanism) into the installation process as experienced by Alice and Bob. We lost that one, for a while, so get over it and move on.
It can be done, the Firefox/Mozilla crowd just proved that, a truly impressive clean install, delivering a great piece of open source software, kudos to that project.
Alice and Bob just want *x to work out of the box. Perfectly. First Time. Zero Learning Curve. No Excuses. No technobabble. No Make files. No Command Lines. No Root. They will use those things, if ever, when they are good and ready, which is clearly Not On Day One. Thats why OEM OS licences are accepted, because it avoids the whole install problem by pre-installing the OS and necessary application goodies. It Just Works.
Unix and its Open Source Variants will no longer be broken, when the *x and Open Source crowd can see past this blindspot. When any and all *x OS or App installs clean in a standard easy way for Alice and Bob.
So, duh, what would I do to start repairing this? Run an Open Source project to nail the use case and provide a common protocol, baseline logic, and any standards needed by all open source projects, oems, device driver manufacturers, and ultimately, transparently, the end users Alice and Bob. A standards and communication type effort to benefit all Open Source projects. Maybe study the FireFox model as the baseline for Apps.
Yeah I know that there have been many excellent efforts, the question did not stipulate picking an easy problem. Its not directly a technical item, its really a standardization and simplification issue. I would contend the *x is Not Broken technically, apart from some nit picking details. Yep there is a lot of needed improvements... So whats new?
The Alice and Bob install use case is an open ended problem, as its addressing a key issue enshrined and entangled in uber geek b*llshit for many years.
Solve the install use case and we can all have a truly open future, on whatever *x OS variant the future may hold.
If anyone is interested in doing something practical with this, please contact me.
Regards and a Happy New Year to all on Slashdot. sd@acm.org
PS: Please urgently consider contributing to the relief funds for the victims of the Asian Quake and Tsunami.
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
This posting wasn't an invitation to laud OS X; rather, it was intended to draw out the problems with UNIX. Since OS X is UNIX based, writing about how great it is seems rather out of place.
Here are the general problems I have with Unix and Unix-like operating systems:
(Note that this isn't to say that every Unix-style system has a bad threading model -- some of them are pretty good, and others are getting better. But it's currently difficult to write decent cross-platform multithreaded Unix code when some Unicies you know in advance have really crappy threading subsystems).
Okay -- now don't get me wrong -- there are a lot of things to like about Unix and Unix-like environments. But those are the items I personally have problems with in the general case (and again, not all Unicies exhibit all of these issues. In particular, Mac OS X doesn't suffer from any of them, and is my current OS of choice for doing development and as my personal workstation desktop environment).
Yaz.
If you were an operating system would YOU want to sound emasculated?
Real operating systems deserve He-Man names. Broken OSes out of Redmond deserve cut-up names.
Sorry, uber-app X version z.w.v can't run because it needs version blah.blah of library 1, you have version blah.suckit - There are 19 other missing dependencies or version incompatibilities...
Here is a project that I think could open up a nice alterative: The Freiburg Project
Project description: The Freiburg project is an infrastructure to replace shared libraries with a client/server interface. This system converts a shared library into a "service" using Unix or inet domain sockets for communication. The "service" will be usable by any programming language without additional C programming requirements. An application is a composition of multiple services using an event-based message bus for communication. A service can reside locally or remotely using the "client" or the inetd super-server for startup.
Oh, yeah the IPC sucks too.
/usr/bin would look the same except that each executable would be replaced with a directory. I do not see how this would help?
Michael
Right:
cvsup
make buildworld
make buildkernel
make installworld
make.conf
rc.conf
You focus on the wrong, I will focus on the right.
No Balls
Thank you! I'm here all week! Try the Chicken Kiev!
It's a trick! I'm not helping you steal my job!
As a programmer, my biggest peeve is that threads are still second-class citizens, and in particular, event delivery is all over the place.
Unix lets you wait for events to occur on file descriptors, signals, shared semaphores and condition variables individually, but not on more than one class of "event" at once. Win32 almost got it right, but it will only let you wait on 64 "events" at once, which is an unrealistically low number these days. QNX comes pretty close with its "pulse" event delivery model. Unix is pretty far behind in this respect.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The boot scripts. Neither BSD nor SysV init both works well and is easy to work with/edit/add to.
I NIT_SETUPS_SUCK for why, and http://www.winterdrache.de/linux/newboot/index.htm l for an alternative.
See http://www.winterdrache.de/linux/newboot/WHY_SYSV
The links go to Matthias Benkmann's site, and to his simpleinit-msb program, a part of his new boot concept. I used it on the LFS system I built a couple of years ago, and while that system is now dead and gone, it was so much easier to administrate than anything else I've ever seen. And besides, it was the most ridiculously elegant thing I've ever seen.
SIGSEGV caught, terminating
wait... not that kind of sig.
1. Since Mac OS X 10.0, you could have used UFS with Mac OS X if you really needed case sensitivity (though, using UFS broke some other things, like Classic, some Carbon installers, etc).
/Volumes/SomeDisk
2. Regardless of 1., as of Mac OS X 10.3.x, Apple now has "Mac OS Extended (Case-sensitive)": a fully case-sensitive, fully supported case-sensitive HFS+ filesystem. It's not exposed in the GUI of Disk Utility on Mac OS X client (as Journaling wasn't on Mac OS X 10.2.x client), but it can be enabled via the command line:
sudo diskutil eraseVolume Case-sensitiveHFS+ DiskName
man diskutil for more info. This is exposed in the GUI of Disk Utility on Mac OS X Server 10.3.x. If you would like your primary volume to be case sensitive, you can use/borrow a Mac OS X Server CD to boot your machine, format your primary volume as Mac OS Extended (Case-sensitive), and then install Mac OS X (or copy back all of your data with a utility such as asr or Carbon Copy Cloner).
Case preservation (as opposed to case sensitivity) was never advertised or presented as a "feature"; it was an artifact of HFS.
There are many usability issues that make me wish I had the money for an Apple, or even winxp. But one that I'd like to highlight now is the relative lack of feedback to commands vs Dos, windows, or apple.
I actually haven't touched the configuration of any of my machines in six months (and the nice thing is, of course, that they all still work perfectly -- not much ongoing maintenance needed), so I can't remember clear examples. But so often, it seems like I'd type something and I thought I knew what it was supposed to do, but it apparantly didn't, and there was no error message to let me know that it hadn't found something to let it work, or whatever.
This sort of thing happened in many areas. One that comes to mind, though, is printing, where everything seems to work fine, no error messages, and everything spooled correctly, yet nothing prints. And since there are several steps in the chain of actually printing something, it's a hassle to figure out which step is the problem. If there was some sort of feedback vis a vis success / failure it would be nice.
As a non-technical sort, perhaps I'm asking for something that's not reasonable and I don't realize it. However, I don't recall having so many problems like that with dos, windows, or apple.
In my 12 years of using UNIXs I never had the need to clone a process. But this is one of the basic API calls. fork() that is. I think it shows that the UNIX API is old -- it has been designed with lazyness in the background -- sure it is easy to write a piped application -- a process gets killed when trying to write to a pipe or something, which has been closed on the other end -- but this "feature" makes it difficult to write something else which is not supposed to die when this happens. Ever tried memory mapped io -- in UNIXs you can open the same file more than once and apply mmap() more than once and a single call to munmap() is sufficient to destroy the results of the two calls to mmap() -- this is not an API which I call up-to-date. That I cannot open a file and lock it in the same instance is something else which ought to be basic for multi-user OS. After I learned about the cool impersonation API in WindowsNT I don't think setuid is cool anymore. Being able to use only a single heap inside a process is another feature which does not match 64 bit programming at all and which creates problems for people trying to run shared libraries inside the same process which load different runtime libraries. Anyway the shared library system has only a single process-global namespace instead of namespace consisting of module name and symbol name. Something similar to Win32 named pipe system should also be basic for a mutliuser OS -- that you have to rely on port numbers for IPC/RPC is not something I call uptodate API -- this namespace (0--65535) is to restrictive.
http://www.adultswim.com/
Peace.
Alright, here's my take. I've only been using Linux really seriously for the past month, so pardon my newbism if you wouldn't mind. ./configure and ./make again, as they never seem to work perfect, especially for the older programs. In Windows, you almost NEVER have to anymore. Double click setup.exe now, and it's cross compatible in most newer operating systems.
- I WANT A GUI
There's no excuse not to have gui on programs. I have to get into the command line practically any time I want to install something that isn't on the Mandrake cd's. Syntaxes are hard to decypher sometimes, even when you're really good at RTFM (which I've been doing religiously to get through this).
- Make everything *everything* install on a COMMON ground. Rpm's are wonderful, but NOT when every single distro has their own way of doing stuff. We need to have a base that everyone comforms to, and keep it that way. Standards are the relaxation of frusteration. Oh, and I NEVER want to hit
- As of the OS install issue everyone's been talking about, it isn't. At least, not when you use the system mandrake uses. True, I've been really frusterated in the past at setups (esp redhat that doesn't detect half my hardware), but with mandrake I did a boot from the CD and, after some intermediate partition managing through the GUI, got it running 99.9% automatic.
- The gaming features will be nice, but those will come. Cedega and Wine need to be more universal and easier to configure and diagnose when there's problems. Do that and you'll have HORDES of windows users coming over. That's the biggest fear I hear from them right now.
DRM in the ipod ? can't the ipod play mp3's and unprotected aac's as well as the drm ones from the apple store ? are you complaining that they don't support ogg again ? or are you complaining that apple sells music files with drm while all the other pay music sites sell unproteced files ? oh wait a minute ...
I could try to individually respond to comments all over, but I think it would be easier just to give my opinion here.
First of all, running processes under separate UIDs/GIDs, while obvious, is a great idea. What makes it so effective in our world and ineffective in Microsoft's is that our implementation of this concept was not an afterthought.
The standard filesystem layout is well thought out, but forking UNIXes have broken things somewhat. Ce la vie; people have different opinions.
It is somewhat irritating that writing portable software isn't more automatic, or rather that it can take a lot of consideration. But we can't force old vendors to adopt new ideas that will break their own monolith, so we're stuck. Ce la vie. GNU libtool/autoconf/automake is a decent hack.
People bitch about hardware compatibility a lot, but that really only applies to certain architectures like x86. I can't speak authoritatively on this, but I'd be willing to bet that (for example) Linux has *far* better hardware support than Windows - it's just our impression that it doesn't because our new multimedia products don't necessarily work natively. In general, this can be fixed - fix the vendor, or choose another.
One complaint I do have from an administrative standpoint is that many UNIXes don't see the need to improve on their userland. After years of becoming accustomed to the GNU userland familiar to anyone with GNU/Linux (and getting what you might call 'spoiled'), I find myself really hating, for example, Solaris. GNU tools add lots of sensible extensions; other vendors should consider doing the same.
Package management would be another bitch. If your vendor doesn't supply you with up to date packages, or if you want to make some decisions yourself (and subsequently compile the software), you can create a big mess out of your filesystem if you're not really careful about what you install and where you let it go. Fifteen billion props to Gentoo on this one - I recently started using Gentoo, and hell if that's not the way to solve this problem.
One annoyance could be the number of overlapping standards and ideas (for example, esd / artsd / jackd / oss | alsa / oss).
All of these things are to some extent the result of people having different ideas. I can't *really* bring myself to whine about any of the above. Different ideas equals innovation. Trial and error, the OS evolves.
It would be swell if programmers thought about security a little more before they busted out into code. Sure, the occasional mistake will happen, but an entire system of cruft always seems to end up trying to being secure thanks to a bunch of hacks, which is a really shitty way to do something.
Note that I don't for one moment endorse the next generation CS-grad-ish idea of doing away with manual memory management by "moving on" from C.
We should vaporize Sendmail and BIND. Numerous better, faster replacements exist for both of these tools, yet the Sendmail/BIND remote holes seem to get installed and enabled by default on far too many systems.
In general, though, it's hard to argue with UNIX. There are tons of flavors, and there are exponentially more choices. If you're like me and think that Solaris is a big fat joke, you can try one of the three freely available BSDs. Or you can be one of those penguin lovers like myself and enjoy you some GNUs-not-UNIX along with a dose of uberKernel.
I like Linux. A lot. I use it all the time, and I develop for it as well. I feel that it will not make a lot more inroads into more general acceptance until some of these things are cleaned up. Users don't generally care if there is a D bit in the protections. They generally don't care if the OS has cool things like logical volumes (like those provided the Amiga's "Assign" command) even if they are really neat, and let me forestall some arguments by saying that I agree that they are. Users care if the machine is easy to use, if the tools they want and/or need are available, and if the machine feels fast -- no one likes buying a 3 GHz machine with a couple gigs of ram and watching a minor application take 10 seconds to load.
So mostly, people don't run Linux. And that's what I think is wrong. But fix it, and they will come. IMHO. As for Unix... I really don't care. :)
I've fallen off your lawn, and I can't get up.
I like the *.app solution of OS X: it looks like a single file, but in actuallity it's a directory with all the files needed for the application to run.
Simple, elegant, and it works.
Well, it isn't so hard to write good software per se (not that it's easy...). Your example with KDE shows that it is possible to have a good consistent interface *within the domain that you control* (i.e. KDE is controlled and written by one group of people who will all agree to write software in such a way to take advantage of the common spell checking).
The real trick, and perhaps an impossible one, is to design a system that has consistency of interface by design. Unix pipes on the command line approach this, but of course not in any useful way to those unable or unwilling to learn quite a bit of command line magic. It just isn't possible to write a program that takes a stream of bytes on stdin and outputs a stream of bytes on stdout that breaks the command line interface (well, it is but...).
Yeah, I'd say we're pretty much in agreement. It frustrates me greatly that when I need to perform a simple calculation beyond what I can do in my head, I leave the computer on which I am typing, fantastically powerful as it is, and reach for the pocket calculator in my desk drawer.
And while I'm at it, I know enough about programming to be dangerous. I can write small applications. But I cannot write anything "professional" complete with undo, redo, spell checking, built in calculator, whatever. If the system was designed so that it could free me, as a programmer, from having to worry about all that, then my small contributions would be vastly more useful.
Of course, like you say, the world then moves on and needs things that were not designed in like indexing. And they may be impossible to add after the fact to such a designed system. Or at least, they can be added but not by enterprising third parties without having that "tacked on afterthought" feel. Certainly a difficult problem.
I would have to say...
What is wrong with Solaris 8
What is wrong with Solaris 10
What is wrong with UnixWare
What is wrong with Redhat 8 Linux
What is wrong with Fedora Core 2
What is wrong with Slackware 10
I cannot really way what is wrong with UNIX as
it is hard to separate out what is UNIX from
what is version XXX of a UNIX-like OS.
Some of the things wrong with UNIX might also
be what is wrong with Windows too.
I can usually say, I like some feature of XXX
version of a UNIX-like OS better than the
implementation of the same in YYY version.
How much of UNIX design is dependent on the underlying hardware architecture? 8 bit byte oriented computers. What would out UNIX be like if we had tri-state logic computers? What if we never had disk drives but had vast arrays of memory to use instead? How does the interaction with the disk controlller influence the UNIX design? The UNIX computers I started working with had ASCII terminals to control them. How much did that influence the design?
...and reread the original post:
If you are a windows person...
Not necessarily just a Windows user.
Maybe there's some merit in the claim that somebody such as an MCSE should avoid *BSD/*nix, since it's likely to be beyond their abilities, both technically and conceptually...but some reasonably astute Windows user, who's simply had enough of MS Windows, may well be capable of making the transition to a better OS, including installing and configuring such a system.
Or maybe you're all right, and the original poster meant that anybody forced to sit in front of a Windows box all day is not up to the challenge, rather than just those who choose to, and who possibly believe MS Windows is the better OS.
I learned by reading Sun's "Guide" manuals that came with SunOS. That was way back in late 80s when Sun was just about to introduce the Sparcstation... I had to switch from VMS to Unix, and SunOS had a set of manuals that included some wonderful tutorials and guides, about shell scription, editing, administration, everything.
Probably, these books don't get published anymore, or at least don't come free with Solaris. But I'm sure you can now buy some very decent books, starting with some published by O'Reilly, that explain everything you want.
Don't forget, Windows and Mac users are in the same boat. They either buy similar books, take courses or have a friend/relative teach them, or learn the basics and don't do anything complicated.
The Unix Hater's Handbook, a free download brought to you by none other than Microsoft Research: http://research.microsoft.com/~daniel/unix-haters. html
Try performing file-system-level backups of a Unix system without being superuser. You can't -- there's no way to set up a user that has read/execute access to everything but write access to nothing.
Managers need to be able to list, create, delete, read, write, and change permissions. [etc]
Writing should also be split into overwriting, appending, and truncating - with having all equivalent to write permission.
For instance: Append without the ability to overwrite or read lets someone leave a message or data without examining or damaging what's already there. Think "mailbox". Overwriting without appending prevents arbitrary expansion of the file, and so on.
Permissions also need to be not just in terms of users, but in terms of users, applications, or combinations of them. For instance: Jerry can use this set of tools to write-append to this mailbox, and that set (but no other) to examine and modify the bug database.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
I can't believe nobody has mentioned this yet. Nobody should work on anything else until I can ssh from Linux, Windows, IRIX, and Solaris to each of the other systems and have the backspace and delete keys always work right.
If you want to use UNIX in a production environment, then you need the equivalent of Generation Data Groups ala MVS. This simplifies production support and tape handling no end.
And this is missing in ALL flavors of Unix and in Linux too.
Oh, and decent production control software too.
That's probably the single biggest problem I see with nix machines. Lazy filesystems have always reminded me of experimental planes developped by the cold war military to up the world speed record. Planes which would basically self destruct if they god forbid hit a pothole while taxying out of the hangar. RAID is obviously not a solution, and I find that backups - while essential for mission critical applications - should not be used as an excuse to allow for making a file system that is as brittle as this.
As a broader comment, I just find that UNIX is a brittle OS. Before every zealot jumps on this statement I should clear up what I mean: the OS components are extremely lean, they do exactly what they're meant to do, but there's absolutely no inherent 'imune system' to the OS. su can go ahead unlink the root node, a power failure and the file system goes to hell, there isn't any cohesive way to manage machine state. Every daemon runs in its own little planet, unaware of everything else.
The article the other day on /. about Sun's attempts at self healing software address parts of this actually. And other really cool apps like tripwire address other points too. But in general, the OS itself is completly stripped of an immune system.
When Microsoft first introduced the Windows File Protection service, I was really pissed off they did something which should have been done via proper security measures (which common users were short circuiting by running as admin). But the more I face the idea, the more I realize that it's not a bad idea after all, proper code signing, system level integrity checks, basically a path towards actual 'self healing systems'.
In general though, everyone has a long way to go still...
The Unix implementation for Goonies fans...
Seriously, who doesn't think Google is or should be working on a decent Unix / Linux implementation? I mean, Red Hat, Novell/Suse and all them are nice but 10 years plus and no significant inroads in the consumer market mean that *someone* new needs to step in.
All hail Google !
I find it interesting as I read through this how many people listed what was wrong with Unix. Very, very few people listed how to fix it.
(Including me.)
I've been using computers for over six years now, so I can tell you I'm in a position to answer this.
I tried Unix for about a week before I went back to Windows. It was practically useless for too many reasons to list, but here are the biggies:
1 - No type of 'My Computer' icon at all.
2 - No 'Start Button.'
3 - No automatic updates.
4 - No AOL client (in this case, 'client' refers to a computer program rather than a person.)
5 - No wizards of any sort, making dialing in virtually impossible.
6 - No Gator or Bonzai Buddy.
Evil is the money of root.
I'm not a programming genius either, but I think callbacks and such will solve most of those problems. If you like, I can try to do what you were talking about.
The idea is to figure out which parts need to be run most often, and which least often -- a general rule of optimization. For instance, it's fairly rare that you'll switch modules, so this operation can be slow.
As an extreme example, imagine that every time a "service" starts or stops, you recompile the program to reflect the new situation.
Don't thank God, thank a doctor!
You know with the trimming of important parts and all.
The GPL, for those that truely understand.
That would allow someone to add a record to a given dataset without being able to remove anything, or perhaps also to modify existing records (depending on the specific implementation).
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
vi
And if you think the answer is "emacs" you still don't get it.
The biggest hurdle to users starting out is vi. What's needed is for every *NIX system to have an "edit" command. It's OK if it aliases to vi hacked to stay in an easy mode and rigged to have a simple menu; the implementation doesn't matter. What does matter is that when newbies need to edit a file they have a simple way to do it with a lightweight editor, without destroying what the poweruser base has come to expect. But this will never happen in a reliable way due to...
2. ...there being too many implementations, and they are all different in subtle ways. Even when they try to standardize it usually does little more than prove the old quip that "standards are good that's why there are so many of them". The only real solution to this is something like MacOS X for the PC, and since we all know that ain't gonna happen, we're stuck with no clear winner for the PC *NIX desktop. None of them have the quality "feel" of a MacOS or a Windows. Yes, that's not a rational statement, but you know it's true. People are emotional. Go figure. Which brings us to a point that others have raised, namely...
3. ...*NIX elitism. I define eliteism as the ability to engage in activity and/or hold opinions that are obviously flawed, and not only overlook one's own flaws, but insist that they are not in fact flaws but are in fact qualities! Elitism is pervasive in the *NIX community. However, it will all but disappear if a winner ever emerges on the PC desktop. It is certainly nowhere near as bad as it was among Linux people circa 1998.
Well, there are more, but that's all I feel like typing right now.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
The primitive filesystem we use under OS2200 has only a single level of directories (called "program files") in the Master File Directory, but we also have both directory and element (file) versioning, allowing one to have a sizable number of files of the same name stored for historical purposes.
That, plus the fact that an element isn't actually removed from a program file when it's DELETE'd until you PACK the file, is something I really miss when using peecee operating systems (be it Linux, Solaris, OS/2, or Windows). Heck, even VMS had a good versioning scheme when I used it in college in the mid 1980's!
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I was simply asking whether the original post suggests that people such as Microsoft certified people may be out of their depth when it comes to high-end operating systems.
I was not insinuating that a Windows user is technically-incompetent by default or definition.
And I'm an actual engineer. Not a "software engineer", or "hardware engineer" or a "network engineer"...I'm an actual, bona fide Engineer, who also happens to be certified in many computer-related systems (Novell, Cisco, etc)...so I feel at least a little qualified to state that the least competent people I've ever met in an IT-related discipline were those possessing Microsoft certification.
What's wrong with Unix is that people don't know what's wrong with it. Let's review a few of the claims posted here:
"VMS you can set people to have read/write/execute and delete. in unix if people have write, they can write it to "null" *grumble*."
Standard Unix permissions do not model the concept of access control well. They were considered elegant at the time given the constraints but now they're just an oversimplification that results in quantized access control capabilities (and the hole you point out). So patching an oversimplification with another one is not a good solution IMO. We can afford to use more than a few bytes to control access and that mechanism should not be specific to file descriptors.
Someone pointed out they didn't like where programs were installed. They suggested one solution was to put everything in a single directory and use links so it's a nice neat package. I don't think we should care where individual files or directories are located. When a program get's installed the system should be sophisticated enough to track what it did so that it can undo it on demand.
Another user believes all config files should follow the same format. I don't think we should be using config files at all. Just allocate data structures from a memory mapped file and write a little menu/form based program to manipulate that data in an intuative way. Then make sure you can export and import the data to and from plain text so we can still do batch processing with scripts.
In general there isn't *that* much wrong with Unix. It's *supposed* to be simple. That's why it's good. MS is much more sophisticated but the complexity has found it's way into lower level privledged areas and now we're paying for it by being required to patch millions of systems every couple of days. I do think there could be changes that would make Unix much better but they're specific to low level sorts of things like the filesystem, shared memory, and synchronization syscalls.
The question we should really be asking is "What's broken with Libc?".
BEGIN 2CENTS
/legacy. In the event there is no specific flag set in the executable (does coff has any flags available for this?) then the kernel/shell would automatically chroot to /legacy before starting the program. Newer shell scripts would be tagged somehow...havent given thought to it. The new filesystem would include an alias feature. This way, we could have meaningful names like /Configuration/Gaim/Preferences/ which could be aliased (aliases for each directory, not for the entire path) to something like /config/gaim/pref/ Case sensitivity should be thrown out. Shouldn't be a problem. Never heard of an app actually depending on thi "feaure". I mentioned Configuration, but what other directories should we have? /Configuration (Like the windows registry. Organized place to keep config data of types like string and numeric, boolean, and perhaps files for the times when the previous wouldnt do the job) /System (Shared libraries, kernel, boot) /Applications (Applications like Firefox or GIMP) /Utilities (Stuff like sort and grep) /Home (It beats the hell out of Documents and Settings...keeper)
It is overall the legacy problem, though drivers cannot be left out. Things that are wrong now have been wrong since the beginning, although at the time they made sense. Things like filesystem layout. Other times it is just that something was created, but multiple or no standards exist. Package management for one.Take MacOS. It spawned from unix, but since Apple controlled every aspect of it they could easily transition. The file system makes actual sense, as do configuration files. Terminal is present, though not nearly as critical to everyday use. Packages, I think it's in an installer format, not sure
UNIX Fixes:
Package management - RPM is nice, particularly nice when you can use a frontend like YaST. apt-get is great. Why can't we find a middle ground? Create a Gnutella/Gnutella2 network for packages. This allows searches without a single centralized directory. Dedicated servers would be needed, as mostly clients would only be on the network while downloading a package. (OSS has found plenty of hosts in the pasts for distros, so something like that would be simple enough) The package format itself could be almost identical to RPM, but what I would like to see is making whether the RPM contains source or binaries totally transparent. May be done already, so shoot me.
Filesystem - the / directory as we know it could be moved to
Drivers - If the above two are fixed then maybe developers would make drivers for UNIX systems too. Until then it would make sense to make an effort to emulate some Windows device drivers. Now I'm not saying this would be particularly fast, particularly reliable, and kernel mode drivers is out of the question. But sometimes you just have to have that wireless card driver that hasn't been ported yet.
Gaming - If people follow Unreal tournament and make games *nux-compatible too, then great. But until then, I believe there was a branch off of wine that runs a number of directx win32 games. Commercial though. It proves it can be done.
END 2CENTS
I mostly agree. I have a lot of ancient Unix experience ,sys7 variants, AIX, etc and in the past year have been involved w/ Linux again. My experience installing Firefox 0.93 was silly, you have to fuss with the install directory (no default nor documentation) or else edit the startup script. That's just pathetic from an end-user POV.
The problem w/ the java runtime plug-in is a glibc revision mismatch and that one took me months to puzzle out.
Sorry, *nix is a great OS, but until the sharp corners are polished off it remains a bag of parts which require expertice to make into a consistent whole.
Are you freaking serious? Making even an extremely simple system call takes on the order of 1000x longer than a method call in the best case (when the kernel just gets access to extra pages instead of a different memory space) thanks to C, assembly, C++, C#, and other non-safe languages. The only real reason why Java is slower is because it is doing more (OO for instance) and safer (array bounds checks, safe paradigm). Other than those two there is no reason it must be slower. And both of those can be 'turned off' for kernel-level code.
Using a safe language like Java, in the kernel gives lots of advantages:
* Turn off virtual memory and MMU == ~30% performance gain.
* No penalty for system calls: rich kernel-level API, 1/1000th overhead from system call, user code can safely access kernel data structures and buffers directly, dynamically inline system calls into application == mucho performance boost.
* Zero language-level security defects (1 bug in Java in like 5 years); no malloc/free / double-free / buffer overflow / off-by-one / etc.
* Safe modules and drivers with no more overhead (objects to mediate access to device memory so impossible for driver to crash the system). Like user-space drivers in a microkernel only without the performance penalties.
* Simplified implementation of basically everything. Have you seen the shenanigans in the kernel for memaging objects in the network stack for instance? Or the ridiculously complicated VFS (virtual file system)?
There are a lot of benefits even for straight Java as the main part of the OS kernel. There are some drawbacks though, so some modifications to plain-jane Java would be needed.
Just because he didn't put the command in the title for easy parsing doesn't mean he's not right.
that that is is that that is not is not
I used to suspect that but then I had it confirmed when I walked past a bookstore's bargain bin and saw 'CCNP for Dummies' and 'Solaris for Dummies'. I shit you not. It was at that moment I realised I was wasting my time and money chasing Cisco certification. It'll cost me more to get it than it'll earn me. That's if all the jobs haven't gone to India first anyhow.
Give me a stable abi and I will give you vendors to support *nix. Until then -- sod off mate.
Look, folks, you're mainly bitching about poor documentation or poor file system organization, with some change left over for not liking the setuid/gid thing which seems like a hack now, but was way cool back in the day.
/etc/passwd to a gdb database indexed on username might be something like /etc/passwd |(gdb) application.
Back many years ago I was proposing something called NERU "a New Enviornment Rationalizing UNIX". Here were some things that I was really interested in doing then:
- uniform addressing schemes that make memory and the file system look more homogeneous.
- typed entities replacing files what carried along their pointers to their own operations. Think of it as an "object oriented file system".
- shell or scripting mechanisms with type casts; say, transforming
cat
- uniform versioning based on copy-on-write: any time you touch a named entity, it automatically has a current version and an old one.
That was 20 years ago (and some of the ideas weren't all that new then the uniform homogeneous model for storage was part of IBM System/38 and is now part of AS/400.)
If you really want to "fix" UNIX, you need something more than fiddling with the file hierarchy organization.
You create a public file with the @CAT,P command, but you can create a new file cycle using @CAT,P FILE(+1).
That will create a new file with the same name but increment the current cycle number by one, and each new cycle of the file is maintained as an independent data file in the MFD, can be independently read to and written to, etc.
The cycle number continues to increment until it hits a certain value and then starts over, which seems like a problem at first, but as such files are usually referenced as a relative offset from the last cataloged cycle, not the absolute cycle number, it isn't as much of an issue as you might think.
Thus, FILE(-0) always refers to the last cataloged cycle of the file named FILE, FILE(-1) refers to the immediately previous one, and so on.
It's very useful for things like daily logfiles where you want to keep around the last 31 copies and don't really care about the absolute file cycle number but want to be able to see today's actiuve file at FILE(-0) or go back to FILE(-10) to see what happened ten days ago.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I've been reading slashdot for what, 7 years now?
.
I've NEVER seen a thread dis Unix like this before.
Never!
I've always held that Unix is to operating systems, what Fundamentalism is to religions.
It served a good purpose; prevent the heretics (Windows) from taking over. Now it's time for a Reformation, I guess. .
A lot of folks seem to be saying that OS X answers a lot of these problems.
Still gots POSIX permissions to deal with tho. . .
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
I have to choose among so many good choices.
Retired from software... maybe. Sort of.
Installing software is highly unreliable, non-standard, a maze of twisty little interdependant passages, and deeply obscure.
True of Linux. Not true of MacOS X. There is no standard "windowing" GUI
True of Linux. Not true of MacOS X.
You have to go to the command line to configure and/or adjust and/or install many things.
True of Linux. Not true of MacOS X.
Find free books.
What's wrong with Unix?
It's name is a sound alike for someone who's been 'snipped.'
How would you fix it?
Well, I don't know about humans, but when you snip a cat, they say it HAS been fixed, but I don't think that works here.
Nix the snippage and give your OS some balls!
Create a directory called FOO for the program FOO that you want to install. Put all the files (.exe file, .dlls, README files, and what have you) into FOO. One nice, happy unit. Unfragmented.
:-) Ideas like /bin and /usr/bin are good ones -- so create a symlink from each application repository to those common directories and be done with it.
Now, add FOO to the PATH and LIBPATH variables if you wish to tell the OS that the executables and/or libraries are to be visible system-wide.
The first entry in the LIBPATH is generally ".", or the current directory, so it's easy to run stuff and NOT add it to the PATH or LIBPATH if you want to. Just CD to the base FOO directory before running the program. A nice job for an alias, shell script, or desktop icon.
With an intelligent CD command like WCD for OS/2 or ACD for DOS (something Linux distro should consider adding, BTW), all one has to do to jump to the location where FOO is stored is to type "CD FOO" in most cases, assuming most programs have relatively unique names. No need to consult with the package manager to see where various files associated with a given package are stored.
It seems like Linux and other Unix-like operating systems like to complexify the issue.
The historical method of splitting up every used-installed package into a zillion different directories based on file type seems to do little more than fragment the system into oblivion.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
they ask this question with reason. Whoever submits the best answer get a job with the GoogleOS group.
If it were not that UNIX was initially given to the universities for the cost of the media, there wouldn't have been so many people who learned how to create programs on it.
If the basic API of UNIX hadn't been so damned obvious and easy to deal with (and adapt to newer kernels, and port to newer hardware architectures) we'd have had to re-invent all the other wheels that today we take for granted - sh (and bash) csh (and tsh, zsh etc.), vi, awk, grep, sed, PERL, etc... and when we re-invented them we'd have fixed all the obvious problems, like "too many args" or ugly text interfaces or non-orthoganal option naming.
If UNIX hadn't been so damned useful, we'd have spent more time inventing new paradigms - and made a truly integrated GUI-OS system, instead of making a useful OS and lots of optional GUIs.
Yup, if UNIX wasn't so damned useful and ubiquitous, we'd have had time and reason to invent something else, - like maybe Linux.
Been there, done that, paid for the T-shirt
and didn't get it
they don't keep whittling toothpicks out of redwoods because it makes them look like skilled carpenters. The cotton gin would never have been invented by a person such as you describe. They'd find great intellectual pride in doing the job by hand.
I'd think the person a complete fool.
Work Safe Porn
No, its unix like, but its not actually unix.
http://www.netbsd.org/Misc/call-it-a-duck.html
I like the ideas I see on ReiserFS future vision. A lot of posts here mention problems with the whole idea of rwx permission bits, or problems with tracking of installs. Applications get scattered all over the directory structure, or compromises are made to prevent that. I thought that ditching the whole idea of a directory hierarchy was the way to go. Reiser FS thinks so too. No more directory trees!
An example to illustrate the problem. Suppose there are 2 apps, "A" and "X11", and each one is composed of many executable and help files. With directory trees, we only have a choice of which mess to make. Throw everything into /usr/bin and /usr/man or create /usr/man/man1/A/, /usr/man/man1/X11/, /usr/bin/A/, /usr/bin/X11/, and maintain package data with yast, apt-get, rpm, pkgtools, or whatever? Or create /usr/A/man, /usr/A/bin/, /usr/X11/man. /usr/X11/bin/ and so on, keeping everything to do with A under /usr/A/? That makes package management a lot easier-- might be able to do package management without a special purpose utility. But doing it that way, just one problem is the PATH environment variable has to be huge, and that will slow the computer down-- imagine working around that by reordering the directories in PATH on the fly-- yechh. Heck, X (XFree86) does it both ways now: most stuff under /usr/X11/, except for the stuff now in /etc/X11/. Why didn't they use /usr/X11/etc? Anyway, giving files "attributes" such as {"usr", "A", "bin"} in an unordered set at once solves the problem of which order to use by getting rid of the requirement to have an order. Also, a flag (rwx and others) would be just another attribute.
We have "namespace pollution" problems, and informal conventions to deal with them. (An example is the bzip2 library, which originally used names like "compress" and "decompress" but changed all the names by prepending "bz2".) How do programmers learn of these customs? Burned hand method, that's how.
Which goes nicely into the 2nd major complaint: C.
Nice to have one language to do it all, except C can't. (I can already hear it: use LISP!) C comes close, and it was brilliant to do all the UNIX software in one language. I think a big reason C beat out Pascal/Modula is the syntax is shorter-- "{" instead of "begin", for instance. But C isn't so brief for other tasks, so we have the makefile "language" and shell scripting (csh and tcsh tried to be like C), to name 2 of the ugly bandaid solutions. This duality leads to the practice of having a "frontend" to use in scripts and from the command line, and a "backend" of library functions to call from C. Why have 2 separate interfaces?
C has another kind of problem: the buffer overrun and similar ilk that arises from the C philosophy of "trust the programmer" and don't make checks because it slows things down. How about the infamous gets() library function? Makes for buggy and insecure software.
C and trees: they were great, they've worked for 30 years. But they're not perfect, and now, after such a long time, we've seen a lot of shortcomings and thought of a lot of improvements.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
-
Unix does not force a specific file heiarchy, so not only do diffrent systems have diffrent filesystems, but one system might have diffrent programs installed with diffrent file structures.
-
It does not impose a certain file layout either, and that makes a big mess in
/etc and the home directory for configuration files
-
And it does not force certain conventions to provide arguments with the programs and you have to use -abc, -a -b -c, or some other variant so that diffrent programs use different ways.
-
It does not force you to program using the ideas of the unix philosophy. (Using small tools connected with pipes, rather than big application programs. That is not all of it, but it is the biggest part).
This "weakness", for lack of a better word is a main component of unix and shows itself all over it, even in Unix's main programming language, C.The power this gives you is great, but when you have a large system with parts maintained by people around the globe, which is Linux, it gets pretty annoying. Standards would have been nice in the beginning, but Standards are recomendations free to be misused, not used, etc. And, even then they fix small parts of the system. one standard for the file-system another for window managers... that just shows the disconnectedness. And some standards would just be horrible if they were set- (XML for the configuration files).
This is not as much as a problem in the big commercial systems where work has been done to make the system seem whole, (even though it is not so great there, either), it is a big problem in linux. Linux is a system with many parts written by many people, but (I) would like it better if each of the parts worked in a consistent manner and were connected
Linux has crappy caching and swapping performance? Really? Granted, none of the boxes I use regularly would qualify as 'high memory', but I've _never_ noticed a difference in the snappiness of the OS over several days... is that true or was he trolling?
Development for apps for "all" linuxs is right out, which means big commercial closed source players aren't interested, which in turn means we have to keep Windows machines around to get some kinds of work done, which sucks.
Actually there are a number of examples which put the lie to your charge, apart from the obvious case where a linux admin doesn't even install a GUI. (linux gives you that flexibility) But a number of commercial vendors provide programs which run on any modern linux distro with X windows, e.g. netscape - but in practical terms, any modern linux distro ships with both qt and gtk apps. So any app built on either native xlib, qt or gtk will run on any modern linux system.
Linux has a pretty poor cache and swap system, combined with zero user level control over cache and swap. As a result, over time, the OS runs slower, and s l o w e r and s... l.... o..... w...... r....... until you restart, and then it's back to being fairly snappy until it fills up memory again with things it shouldn't be caching,
LOL, mod parent up funny - linux memory management is actually pretty decent. I don't buy into the hype about running slower and slower and finally needing a reboot, that sounds like too much microsoft thinking. Our mail servers which are currently on a 700+ day uptime are processing messages just as fast as they were when first booted.
Sorry, your story just doesn't hold up.
C's big problem is the same thing that made it so popular with programmers when it first came out: pointers. C's pointer syntax was new and cool, and programmers used it like unprotected sex on a Cuban vacation. That's why we're still hearing about new vulnerabilities in sendmail. C++ fixed something that wasn't a problem with C, trying to bring it in line with the OOP fad, while maintaining backward-compatibility, and therefore ensuring that it would be a monstrosity. Meanwhile, C++ failed to fix the basic problem with C, which was pointers. Oh yeah, and it brought with it some new problems; every time you change an exposed piece of class data in C++, it breaks binary compatibility, and that's one of the big reasons that software installation is such a nightmare on many flavors of unix (not including MacOS X). C was designed as a language for systems programming, and it was great for that, but people should use the right tool for the job. There is no excuse today for writing applications programs in C or C++. At most, a few time-critical routines should be written in C or C++.
Shell is the other problem with Unix. For one thing, there are too many shells. If you don't believe this is a problem, do a "man bash," and read the section titled "INVOCATION;" it's a huge mess of confusion required for backward compatibility with other shells.
Another problem with shell is the flat namespace. F'rinstance, ImageMagick has homesteaded the verb "convert," so nobody else can ever use it. I have a script I wrote called "view," and one of the first things I always do when I install Unix is to remove the "view" that is a symlink to vi.
Basically a lot of the problems with shell come from the fact that Perl was invented too late. Shell has lots of comprimises between (a) the ability to do things quickly and easily in a terminal window, and (b) the ability to write programs.
Find free books.
..as a Mac admin since '97, it's blackly amusing that now that Apple's shipping unix, all my old linux friends are now flaunting powerbooks. :P
:|
OS X takes the bullshit out of getting Work Done, and that's nice- but in the process, the platform has transitioned from the domain of artists and eccentrics to the khaki-clad GAP-shopping technoratti richass motherfuckers, who have no use for any of the reasons the platform has continued to exist over the past 20 years.
My OS-that-runs-Art doesn't exist anymore. Apple's replaced it with an OS that does everything but Halflife... and to get that, they had to round off some of the edges.
Yes, there are reasons that people don't want to reboot a production server. I ahve operated and then administrated production machines in varios settings since the mid seventies. I've worked five-nines government contracts. I know about down time.
/etc and /bin and /lib (completely out of symlinks and bind mounts, e.g. no copying and no duplication) to satisfy those dependencies.
/etc directory have in common should be fairly obvious. My intent is obliterate /etc as a static entity. Most packages should have their own configurations instead of bonus directories in /etc. So when you put in SSH version 2.2 the entirity of the ssh, config and all, would be in /apps/ssh/2.2 (so /apps/ssh/2.2/config). Of course, some things [like SSH oddly enough 8-)] might rank "config packages" to share the config between versions. Sounds unnecessarily complicated until SSH 11 comes along and has incompatable configs to prior versions. When you started up --with-ssh-11 your _effective_ /etc/ssh would be composed from one sourece, when --with-ssh-2 your _effective_ /etc/ssh would be from somewhere else completely. This would be controled by the dependency files/language. And so forth.
/etc and /bin are the essential problem. If these directories were composed into existence at each boot from disparate persistent sources based entirely on dependency requirements, then they couldn't get polluted over time because they would regularly be recreated from whole cloth.
No, you don't "have to reboot to execute something from a removable media."
You reboot when you want to fundimentally replace a package. (And maybe not even then if the facility were written correctly and had the necessary tools to determine that a full reboot weren't necessary and a hot recomposition could be performed.)
[note: all version nubmers chosen arbitrarily, as example, not to reference existing verions particularly]
The core idea is that what we think of today as the backbone of *NIX is a static pile of doo-doo that gets poluted too easily. If, instead, everything were safely ensconsed in it own directory and "properly documented" its own dependencies to the outside world via a parseable file full of directives. (e.g. a file that said "needs binutils, needs fileutils 2.8" etc) it would be easy for a tool to "compose" things like
The most obvious time to do this (and the one time it is mandatory) is during reboot. Reboot is also ideal to prevent the race condition where, lets say, you were replacing binutils 2.10 with 2.30 and you didn't want to worry about the mixing the output of both because someone was compiling just when you made the change.
The first version of this facility would certianly be reboot-centric. See my other comment(s) in this thread for a longer example of the possiblities including things like MakePrivateRoot as a chroot-like command that compose-and-chroot-and-exec(s) a process in its own limited and custom environment. (yes, it would be expensive, but the fact that it would be possible is significant.)
What the system and the
Dont think about this statically. The static and pollutable
The point about the removable devices is different. It's not a limit, its a feature. In a situation where machines are loaned-out to individuals (as in computer labs at schools, and cyber caffes) it is _normal_ for people to lug in whole drives full of their own work and plug in. If the core system was set up to compose-in-at-boot the external drive, while the core packages and configs were frozen on a read-only drive [think read-only via jumpers not permissions], then the core machines woudl be "automatically customized" by the portable media, but they coudln't ever be "compromised" by them. So the school in question provides the base machine and the 20 or so pac
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Note: We are talking about UNIX the operating system kernel. The question is not about the applications that run on UNIX.
My wish list:
1. Event handling: UNIX has a silly signal() as the only signal handling mechanism. I know, I know there are 'extensions' all around, but we are talking about UNIX per se. select() is a kludge. Try handling 10,000 slow TCP/IP streams (think Instant Messaging) on an 'extension free' UNIX to see what I mean.
2. Lower level file handling: If only could I handle a file with it's inode! Dont' think this is arcane. There are a lot of useful things that could be done if this were possible (and cut down the time File system takes to parse a path name).
3. Instant volume mounting: The only good thing about Windows is that I can quickly plug in a removable media copy something and yank it off. None of the silly mount/umounts. I know, it 'can be done' with some intelligence at the app level. I am talking about the kernel you silly!
4. Quicker booting: I wish the system took less than 10 seconds to come up. at least on the CLI. But this is a personal wish.
5. ioctl() madness. do away with the 'there-is-ioctl-for-the-rest' mentality. C'mon guys, it is a kludgy way to pass data around through the kernel.
The purpose of all philosophers was to impress women
I've had the same experience with Firefox and plug-in installs (under MEPIS Linux), finally got a work-around by linking from the Firefox plug-in directory to the Mozilla plug-in directory where the installers were actually putting things. Would be better if the installers were Firefox aware. Then, I "apt-get upgrade"d my system into oblivion, and had to reinstall from scratch, actually went fairly smoothly, my home drive was preserved perfectly - but I lost all my plugin links and custom installed libraries I need - at least the Firefox bookmarks are in home, they were saved.
Back off the tangent to the thread - the eliteist attitude of *nix shows in so many ways, and it hurts widespread adoption, which is to its ultimate detriment. Auntie M may think a boot screen that says "GRUB" in plain text is funny, and slightly disturbing - leading her to choose the more "normal" operating system. Try selling your mainstream boss a development environment supported by some Scandanavian guys who call themselves Trolltech... all these little attitude statements add up to keep the rebels on the fringes of the galaxy.
Of course, if you like living on the ragged edge, just keep putting out seriously good software with dorky icons and queer names - it won't bother the people "who actually have a clue."
Clue: 90% of the population doesn't have a clue, but with numbers like that the clueless are an important force to be reckoned with - especially if you're trying to earn a living.
You guys are nuts. The biggest problem with LINUX, (who cares about unix anyway) is that its so damn hard to configure and use, I use linux at work, and while I love it, windows is in a different league when it comes to things like ....... printing. I myself think printing is one of the fundamentals - my printer btw is a laserjet III, not exactly uncommon - I can set my screen resolution in seconds.... YAST2 crashes my machine if I set some resolutions (which it ALLOWS), until I run some ghastly utility calles vga probe or suchlike. Right now, linux has only a few good things.
1/ the apache application
2/ the samba application
3/ it never crashes (up 1 1/2 years - no crashes) and,
4/ application crash recovery is easy, without rebooting (at least for apache)
I also use solaris at work - Linux is leagues ahead except for stability (solaris is AMAZING FOR STABILITY).
As regards usability vs windows....any self respecting windows user would trash it in seconds, the whole user experience is crap.
So it does not run under Linux either. Here goes my only reason to migrate from FreeBSD.
1. select()ing files actually demands that read() not block.
/opt/AUTHOR/PACKAGE/VERSION/ or something acceptably similar. use join() to pull in their bins and libs into the main namespace if desired.
2. shadowlink() which allows for rename()ing the original to atomically update the shadow()
3. rename()ing a file into a directory that's opened has it's entry added to the end of the readdir() queue for that other process IF the original name hasn't been seen in that directory [yet]
4. join(a,b) syscall which attaches directory b's contents into directory a for this process and all children. a complementary unjoin(a) and unjoin2(a,b) which remove all joins, and a specific join respectively.
5. fork() return a file descriptor. writing to the file descriptor sends that signal. reading from the descriptor wait()s for it's status. close()ing the file descriptor detaches. if you really wanted to, getfpid(f) returns the opaque pid of the peer on f. getpfid(p) does the reverse. getpfid(-1) or 0 returns the file descriptor for the current process.
6. splitsocket(s,&i,&o) returns a pair of ofiles. reading from i is the same as reading from s. writing to o is the same as writing to s. closing i is the same as shutdown(SHUT_RD); closing o is the same as shutdown(SHUT_WR); closing(s) after splitsocket() does nothing.
7. poll2() which uses struct poll2s which are a linked list and have a void*userv; for user data.
8. disablenetwork() which kills the current process and any child processes ability to use routable network traffic.
9. bootnumber() and poweronseq() which return the number of boots this system has had and the number of times poweronseq() has been called by any process. these together can be used for sequence number generation.
10. daemons are stupid. let the shell background them.
11. seek() on a pipe will generate a SIGPIPESEEK on the peer if the peer handles it (default/ignore is to generate the normal error with no side effects). that signal has in its sigaction the desired offset.
12. postfd(f) returns a 1024-byte random token that another process can use getfd(tok) to get that fd without using any other communication channel.
13. mapf(addr,len) creates a file descriptor from the current process address space. mmap()ing that fd can reobtain that address space - even after exec().
14. insist csh be never again used for programming.
15. audit(f); system call which raises SIGSTOP for this process (and all children) whenever they do an operation that touches f. if f is a directory, then this includes all children of f, ignoring symlinks. a debugger can notice this.
16. anonf(x) returns a file descriptor that is backed by some inaccessible file space without a name. if x is >-1 then it will be on the same filesystem as "x" is, and thus flink() or frename() is possible.
17. flink(f,name); links a file descriptor to a name as link(a,b) links two names.
18. frename(f,name); maybe freplace() instead, but replaces name with the contents stored in f the way rename() can be used to atomically replace files.
19. open() flag O_LATER returns a file descriptor now and fails on the first read() or write() if the file couldn't actually be opened.
20. stop screwing up my filesystem! "#!" should search the path, shared libs should search all paths, and software packages NOT WRITTEN BY THE VENDOR should be in
From plan9 (unix done better) developer and Pike's buddy Dave Presotto a.k.a. "a strange man who needs no introduction" (also avail at the plan9 faq and comp.os.plan9).
...).
...
...) they all eventually got jammed in. We wanted something simpler to work with.
Subject: What Unix Problems Were Too Deep to Fix?
This is best described by Dave Presotto's 9fans post (from 7 May 2003):
Before Plan 9, we were running lots of Unices held together by a few networks, a remote file system (different uid's on each Unix), and a bunch of remote execution commands. We hated it since it was much harder to manage and use than our old single mutiuser machine. We wanted an environment that not only put together a lot of boxes and made them look like one but which also would make use of the new technologies that were appearing (SMP's, heterogeneous architectures, juke boxes,
The thought was that the new environment wouldn't change from Unix except where we thought it would make our goal easier to build. The kernel had to go. The single monitor view of the Unix kernel was a real pain for making good use of the SMP's. Therefore, we started that from scratch. That didn't mean that the kenrel interface had to change though. That was a separate topic. Lots of others have rewritten the kernel from the ground up while maintaining something that looked more like a Unix.
Ken and Rob thought up the idea of building everything around a single file system protocol. They also added the idea of a subjective namespace to try to unify all the binding ideas of Unix. This name space is the one thing underlying Plan 9. We could have done the same thing to a Unix kernel (with an infinite amount of sweating) but the result would have been the same from the user standpoint, i.e., a system that looks very different. The ease which with it can be done can be witnessed by the number of failed/stalled attempts to add the Plan 9 namespace to Linux
Also, we were tired of the general kitchen sink nature of Unix, especially of System V. If there were 3 projects or groups to do a single thing (like character processing, shared memory, networking,
Lastly, we had all developed an extreme allergy to code filled with #if, #ifdef, #else, #elseif. Getting rid of that cruft by sticking differences into separate files/routines required a hell of a lot of rewriting.
So the result was a different kernel, with a different design philosophy, a similar but different interface, but mostly the same old commands.
If you think that Unix was just a single track in comparison, you're sadly mistaken. We just made more of a bend than others did.
We are guilty of rewriting commands just for the sake of doing it. The reason there was sometimes legitimate, to match our different kernel interfaces or whatever. However, it was just as often so we wouldn't have to worry about Unix licenses.
===
This pretty much sums it up.
justine.
Look.
Commercial software on linux works exactly as you described.
MATLAB? Self contained.
Oracle? Self contained.
Mathematica? Self contained.
StarOffice? Quake3? UT2kx? Clementine? Rational ES?
Self contained.
If the software is supported by the vendor, then it's probably completely self-contained; you could probably run it off CD-ROMs with some path hierarchy trickery and a very barebones linux system. Most package java internally, if used.
OTH, almost all of the software you see that comes with a distribution is OSS. Most OSS software is dependant on other OSS software in a large way. This requires sharing of files. So rather than trying to support multiple versions of a library or audio daemon or whatever, you have one instance of the common component.
This way, upgrading that one component will upgrade the experience of all the dependant software.
Similarly you do NOT see the drag-n-drop installation of OSS packages in the Fink environment in OSX, right?
Right.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
and rob's better window manager: www.cs.bell-labs.com/who/rob/lec5.pdf
Many people are quick to say that if (l)unix 'were more like OSX' it would be better. While I agree that OSX is a nice operating system, has a good set of utilities and built-in programs, and provides a nice, friendly user interface, the same results could not be achieved in (l)unix.
The reason Apple is able to devote time to making the GUI pretty, or creating these great applications is the limited hardware base they support. Mac OSX has nowhere near the hardware support provided by Linux or Windows. Don't get me wrong, the PowerPC architecture is great, however, the lack of other options concerns me. I personally try to avoid vendor lock-in as much as possible.
I personally would like to see better vendor support (Ie ATI ).
Also, while competition is great, it would be nice if the main windowing systems (KDE or Gnome [QT Vs GTK])were more compatible with each other (or we just choose one). Being able to run QT apps in GTK without loading all the extra KDE nonsense would be nice....
Last note, greater standardization would be good too. Choosing *one* package management system that could be deployed across all dristros would be nice (Perhaps incorporate the best of the existing package management systems into one, cross distro system). It would make it easier for developers (only one package to make), admins (got a few different distros? ), and the general public (if more people use this utility, chances are a greater portion of those people will donate money, time, or other resources to the project).
The W3C is an interesting idea, but *it* may not be the best idea. First of all, having a central organization setting standards does *not* mean those settings will be followed. Take, for instance, CSS. The standards are clearly defined by the W3C, however creating CSS documents that look exactly the same across IE and Gecko browsers is not easy. Moreover, people complain that getting features into the kernel takes a long time already, adding bureaucracy will only increase the delays....
Excellent points are made in many of these replies, and what we need is to take the best of everything; the clean GUI of OSX, the standardization provided by a consortium including industry vendors, greater vendor support, and unify some of our efforts.
Competition is good, but only so long as it does not ultimately make the users life more difficult.
My answer was how easy it is to remove files permanently. There should be an option to archive files when deleting in a ..Removed directory. This would be similar to ReiserFS's way of ensuring directories are not corrupted while removing, but it would be permanent.
What's wrong with Brewster?
That question is bad for so many reasons. Unix is great for many things. People are working to make it better. It's getting better faster than windows is. If you want unix to do something better, help fix it.
What would be nice is if distros would include a profile.d that had a script called "env_manage" or something that might work like this:
/etc/profile.d/env.d/*.sh;
/etc/profile.d/env.d/package_name.sh
P ATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib: $ORACLE_HOME/bin
for each in
if basename of *.sh is not in USER_BLOCKLIST or the first line contains MANDATORY
source $each;
fi
done
And you'd have a lot of files like this:
For example, maybe oracle.sh
### MANDATORY
ORACLE_HOME=/opt/orahome1
LD_LIBRARY_
PATH=$PATH
export ORACLE_HOME LD_LIBRARY_PATH PATH
And the package manager could maintain these files in the env.d directory so that each package can live self-contained, but this one script does everything necessary to make it visible in a user's session.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
As for your comments concerning development for Linux...
The lack of a "standard GUI" is not a problem that exists for Linux. For Unix in general, perhaps, but all Linux distros (and, really, most modern UNIX desktops) have GTK, and many have QT. I can run GTK applications perfectly fine under KDE, QT apps perfectly find under GNOME, and both fine under twm. They look like native applications of my desktop of choice. Soon, they'll even have the option of using the dialogs of my desktop of choice, but standard dialogs haven't been a stumbing block on Windows, either.
Your problem of GPL-or-commercial-only is something that is only true of QT. GTK exists, is LGPL, and it works quite well. If GTK isn't suitable, there are other toolkits.
F* you if you think it's too hard to use, go F*-ing program it yourself if you want feature x,y,z, F* you if you're too stupid to read a man page, F* you for asking when the next release comes out, etc, etc. You people know who you are -- you're not special because you can use UNIX -- please get over yourself.
Elitism is ugly and it should stop.
how pathetic. why slave your time copying someone elses piece of crap when you can craft your own?
i'm rapidly loosing faith that operating systems are in any way different from each other. its like arguing athlon/pentium: for the most part its the same bloody thing.
there's a million little operational differences but those are never going to take the windows crown. what we need is something different, something actually better at a deeper level.
its called innovation:
think on the boundary
build past it
Why not run the Linux version of Firefox under emulation? Install the linux gtk2 libraries and it should work fine.
FWIW, the typical problem here is that flash gets compiled with a different version of gcc than Firefox, and then Firefox can't load the plugin because of g++ ABI issues. So depending on whether you're using the Fedora Firefox or the mozilla.org Firefox or whatever, you can have different results on the same machine. The other thing to check is that the plugin ends up in the right directory, since that's changed at least 3 times in the last 6 months. I personally prefer ~/.mozilla/firefox/plugins/ since that doesn't get wiped out if you d/l a new mozilla.org build and install it. You go to about:plugins in Firefox to make sure the plugin is actually getting loaded.
Your ignorance of computer languages is overwhelming. I'm guessing you're still in school and Java is/was the first computer language you've learned. Come back to us when you really know at least 10 others.
I for one would like to hear from Bruce Perens on this. Other celebrities too, but I know Bruce actually shows up here occasionally ...
One simple rule for its versus it's
* customizing
* configuring
If you want simple, you can't have those two. If you want to customize and configure, you have to accept some complexity. You have to be willing to make choices.
Are you telling me that "more power" has to be equal to "more checkboxes in a dialog" or "more command line switches"? If you are, you're missing the WHOLE POINT!
Take Firefox, for example. It has options, advanced options,and advanced tabs in the advanced options. But that was NOT what I was talking about. It's this whole apt-get / recompiling business.
Apt-get NEEDS THE INTERNET. What if I'm over a 33.6K connection but I have a DVD drive? Huh?
Linux needs standards as how apps interact with each other and the environment, so someone can make an EASY PLUGIN to configure all that stuff. But guess what, you can't. People in here have talked about how Debian is superior to Redhat, and how Redhat improved over the years... I don't want Debian or Redhat, or Brand-X... i want LINUX. I want a configure tool that is compatible with not redhat, or debian, or whatever... but ALL OF THEM JUST BECAUSE THEY'RE LINUX. I want to pull a CD which says "Linux compatible", insert it into the drive bay, so it will use the STANDARD procedures as said in the OFFICIAL LINUX SPECIFICATIONS (which don't exist so far), so that i won't EVEN NOTICE what the heck the program's doing.
You talk to me about the pros and cons of the different Linux flavors... but I want ONE WAY OF LINUX. No matter how customizable it is. Say all you want of self-organization and how the beauty of free contribution, whatever, but right now you can't give me a "compatible with Linux" stamped CD that when I insert it in whatever Linux flavor i have and no matter how customized i have it, the program will INSTALL AND RUN with ZERO problems.
Can you give me that? If you can't, then you're just realizing the problem. Linux doesn't have "operating specifications". It has "how-to"'s, which in other words, tell you "how-to" get around the incompatibilities.
You forget that it's the standards which make the WWW a much cleaner web than 10 years ago, with all those proprietary extensions and workarounds that people use for compatibility. I'm just saying that if Linux uses standards (low-level standards I mean), the upper levels won't have to worry. And we wouldn't have this whole configure/recompile/apt-get mess to simply install and run my mp3 player app or something.
Oh, by the way, if you think LISP guys are bad, try asking something (anything) in #perl sometime - the answers you will get will be divided into two categories:
political_news.c: warning: comparison is always true due to limited range of data type
- Provide a true serial console solution for x86 hardware that enables everything from BIOS changes to OS install on bare metal - this would bring the X86 platform up to where UNIX was 20 years ago (and don't tell me about IPMI until there's hardware using the 2.0 spec)
/usr/local/ for that. Nowadays, Linux treats everything like it belongs in /usr. What exactly is *not* a system binary or library in a linux distribution?
/sbin and /usr/sbin? - Give me *one* - how about only /usr/sbin so we can keep / with fewer entries?
/bin and /usr/bin? How about only /usr/bin.
/usr/share/foo vs. /usr/lib/foo vs. /etc/foo vs. /var/lib/foo vs. /opt/foo vs /usr/local/share/foo vs. /usr/local/lib/foo vs. /usr/local/etc/foo .... Kill me now, please!
/etc/mailcap if it exists and is properly configured. Write a simple GUI to configure /etc/mailcap and then all mail apps will be happy
- redo the whole privileged port thing. When only root could become UID 0 and start a process on a port under 1024, maybe this meant something. Today, it's a joke
- kill the GNU info format. Could anything possibly be less useful that INFO pages?!? Sheesh. Manpages have become a standard - Everything should have a manpage.
- Manpages must provide at least 5 example command strings for sample usage with description of what those options do.
- In the days of UNIX, we all knew what were system binaries and what was GNU/other. We used
- Central area for Internet-based config files. Try to set web/ftp proxy information in a single location and have it honored by more than one or two programs
- Strict adherence to commonly used environment variables like HTTP_PROXY, NO_PROXY by any internet-enabled app. There should be more like NNTPSERVER, SMTPSERVER, IMAPSERVER, POPSERVER
- Do we really need
- Do we really need
- for application foo, what should go in
- sar was great, but I need a year's worth of data, and I would really like to have some trend analysis automatically done and know that my bottleneck over the past week has been XXX and was due to process YYY
- mail programs should all be able to default to using
- Make X11 session state transportable. I want t o be able to transport my entire X session from one Xserver to another Xserver without losing the state of any apps. (not just a view via VNC... the whole GUI app)
Back when I was still using RISC OS (an experience I would gladly go back to if I'd the money for a new machine), all our apps were packaged in their own directory. It all worked tremendously well! This page explains it well enough. There's no sense in me rehashing the whole thing here. Really, go take a read of that.
Oh, and I don't think the RISC OS FontManager's antialiasing has yet been beaten when it comes to quality. Nope, it's still the best font rendering engine around.
I don't like trolls and mod against me if you like, but I'd prefer if you'd reply.
There isn't much wrong with Unix, IMHO. But nothing is perfect. I believe a lot of other replies, however, have concentrated on particular incarnations of Unix.
/dev/ to manage permissions. For example, posessing an open file descriptor on /dev/security/tcp/lowsocket would permit applications to open sockets below 1024.
/dev/security/tcp/lowsocket can be opened by any process whose text comes from /usr/sbin/in.fingerd.
I think the one thing that was a mistake was making UID 0 special. Rather, I think they could have made more use of nodes in
This concept could have been combined with, perhaps, a process-based ACL system - something like
I haven't really thought this through much. It's just a first stab, the idea being that far too many things wind up having to be SUID root just because they have to do one privileged thing.
I Dont understand why your bashing Unix alot of the things everyone is saying are all lies. I Use Unix everyday running a commercial UI also known as OSX. Not only is it one of the most Stable Operating systems ive ever used its probably the easiest one to use as well. Although its true power still lies in the Unix command line any typical computer user would be set with the UI alone. every thing from application installation/Uninstallation to editing existing programs (even commercial apps) to fit your needs is easy enough for even someone with almost no computer knowledge to accomplish. So please dont bash something based on only one gui
The File System. In particular, the permissions system.
While the file system and its permissions are quite well thought out, and has a huge amount of capabilities, it has one fatal flaw: It is not able to have the fine-grained control that other file systems can offer. This, and this alone has caused me great greif and dispair with making a file server for many a thousands of clients, and has, regretabley, forced me to use a Windows server I was hoping to replace.
The crux of the matter is the inability to control on a per-user level the permissions of any one file or directory for a multiple number of users. Being restricted to an Owner, Group and Everybody Else for permissions is sufficiant in most, but definatly not all surcomstances.
If I were to fix this, perhaps I would do this in two steps. First, the bandaid which would be backwards compatible with the existing system: Allow a group to be a member of another group. Doing this would allow much more flexability in assigning the permisinos I need.
As an overhaul, I would ask that the entire permisions system be scrapped for a well thought out solution. I am not one to dream up such a solution, but I'm sure the collective minds of the open source comunity can provide adequite brain power to enhance, or even revolutoinize the permisions system.
But, perhaps as it has been known to happen, the solution to my problem has already been found. In this case, I would ask that you please reply to this post and inform me of the permissions system I have been yearning for. You would make my day.
Do you have a problem with case sensitive file names in Gnome or KDE? No, because the file picker does all the footwork anyways.
/home/dylang/txt/school/cmpt801/thesis.pdf.
:)).
I do agree there are warts and leftovers that don't seem useful to have, but I'd argue that some of them (such as case sensitive filenames) can be solved in more meaningful names. Filenames themselves are a shitty representation, chosen only because it was easier (at the time) to have a string in a dentry to describe a set of inodes, rather than having a TRUE representation of the meta-data of the file. OS X.4, BeOS, HPFS -- all have extra attributes to handle this and make life easier. Reiser is moving this way, too. I think a more meaningful solution would be to have the system automatically catagorize all data via filesystem attributes (rather than file(1), even though it works very well), and have automatically generated sets of keywords (perhaps using technology similar to Google search).
Then, you could just tell your word process to open your CMPT thesis, instead of open
Wouldn't that be worth all the effort you'd otherwise spend? Especially with tab completion, case-sensitivity is a small issue that is better address by just trashing filenames as the primary method of dealing with data (IMO
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Maybe this is a nit, but it's what turned me off about Unix many years ago. The standard utility names are mostly silly or meaningless. The mainframe system I used to use had long meaningful names for standard commands: copyfile, rename, delete, listfile, filelist (the latter fancier than the former). You could use any abbreviation for any of these commands that uniquely identified it, or you could invent your own synonyms. This meant that you only had to type a couple of letters to identify a command when you were working interactively, but in scripts you could spell out command names for readability.
I don't think that I was the only one who though of Unix as a goofy college experiment where the pioneers of the system wanted it to be a cryptic as possible to maintain their "elite" image.
While it's nice that there is such a wide selection of shell environments, scripting languages and utilities from which to choose, it would also be nice if there were a widely accepted core set of these things that EVERYONE was familiar with. Maybe the popularity of Linux will create such a core set of components as a defacto standard in the long run. I don't see it happening in any formal way.
I believe that nothing is fundamentally wrong with Unix. Unix is an operating system designed to work best for certain computing applications, and it works very well in that respect.
Unix is not meant to be an office desktop operating system, so any complaints about how it compares to Windows or OS X are irrelevant. Not all operating systems were created for, or are used for, the same reason.
In addition, I also believe that there is nothing fundamentally wrong with Windows or OS X, either. They were all designed with different things in mind with varying priorities; and, for the most part, they all do well at what they were designed for. Of course, all operating systems have bugs, glitches, various problems, and things that could be improved upon, but that does not make them wrong or broken.
Not that it's worth much with all the other stuff already out there but here are my thoughts.
1st are they talking Unix (or including Linux too). If they are just talking Unix,
1) The software is (was) too expensive up front. This affects both the initial decision for purcahse and the ability for the average Joe to buy a copy install on his/her home system & doink around on to learn it well.
**Note: I am aware that sun is now offering thier os for free for personal use. It's about time Unix started supporting their potential future techs.
2) Compatability/drivers for cheaper old generic hardware. Alot of the stuff I buy is cheap hardware which doesn't have much in the way of software/driver support. This affects the total cost. For the past 6 months I have wanted to by a couple of cheap $350 dollar systems to play with, but I don't know if it will support Unix or Linux out of the box.
3) Core user software basics are there. I don't know if I can find (or easily find) good sound software, graphic editing software, IM tools, yahoo toolbar (they got me with disposable e-mail addresses), wireless support, print drivers.
4) Learning curve. Yes, maybe they do need silly ass tutorials for the new users to help him/her get running on the basic stuff first. Once you have something you can use for the day to day task you can begin learning the more indepth stuff.
5) Ease of patches - Redhat had a decent setup going. But now that autoupdates are a paid service, I am not sure I want to spend more money that I would pay microsoft upfront to get them. I fully expect Unix/Linux to start getting hit with the same problems that Windows has. It's just a matter of critical mass.
6) Too many options for the first time user. I don't know which distribution to pick.
7) To sum it all up: Fear, uncertainty, doubt, ignorance, money.
If anyone wishes to help me out with any of my issues I would be more than happy.
But for now, that is all.
Self-respecting Windows user?!? Now that's rich!
There was Cowboy Neal at the wheel of a bus to never-ever land.
UNIX was built in the 1970's. It has reached retirement age, and then some.
No, *you're* the dummy.
Come back to us when you really know at least 10 others.
Why not actually try to make some sense? I've done plenty enough unix kernel programming in C and assembly to know wtf I am talking about.
Grow up. Get a brain. Then use it.
Apple Developer Connection (ADC)
Hello World at ADC
Clearly not a Unix man page per se, and that isn't the job of Unix man pages. That is the job of MSDN. MSDN does it very badly.
I can't get it to run Windows XP or AOL :(
We have secretly replaced these Slashdot mods' sense of humor with a rusty nail. Let's see if they notice!!
Another reason apple is bringing unix into a much better place. The "UserDefaults" system and plist files are a great format and system for storing and looking up configuration. Standard files in standard locations in an easy to read format with simple apis and tools. The api even transparently checks if you have a preference, and if not reads it from the system default.
0 0356.html
Another unix problem fixed with OS X is directories and versioning of libraries etc. with their bundle system... and IPC (and even RPC) using cocoa requires no thought at all.
ok so, apple is fixing unix, but here's what's still broken: http://www.drunkenblog.com/drunkenblog-archives/0
No naked pictures of Heidi Wall dammit!!!!
Yes, it works fine under Linux. You just have to link the plugins in the mozilla plugins directory to the plugins in the firefox plugins directory. The Flash installer isn't aware of firefox, so it doesn't install the plugins in the right place. This is an issue with Flash, not Linux, or Firefox. If you install Firefox on Windows, I would guess the same thing would happen. This may fix things in FreeBSD as well.
If this was supposed to be a joke, sorry for not getting it.
What's broken on UNIX ?
Pipes get broken regularly, hence the broken pipe error message !!
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
I read many of the coments and complains posted so far. Many are implementation specific gripes.
Some are architecture specific, but Unix is what it is. You really can't change that. And that is the root of the problem.
I mean Unix was/is a major step forward. Almost all major OS's have a unix like engine under the hoods these days(MS Windows included).
Unix has accomplished every goal originaly set out for it. But it's also very limited in it's own over all vision and architecture.
To overcome that requires finding a very different way of thinking about programs, OS's and computers then the way we now do.
For example, I can access a remote machine with VNC. I love it so much I have several PC that I almost only access that way.
There are many significant adventages when using a computer this way that most people don't realize.
1.) When I log in, all my applications are right were I left them. Windows open, word processors and E-mails half written, cursor sitting just where I had last contunued even though I many have flown 2000 miles. (or had my local computer reboot)
X windows can't do this! Although I love X for many reasons, X tunneled over SSH is very cool. VNC also tunnels.
Back in the Early 90's Novel had something sort of like this, at least your whole windows work enviorment and files would follow you from computer to computer, but would loose run time states. Sun is also working hard on systems like this.
2.)Thing like IM and E-mail , gnutilla etc continue to function even when I am not online.
In the command line world we have had this in UNIX for a long time "nohup" and "cron" for example.
But why do I need a graphics card at all. Why can't I just have many virtual desktop sessions that I can VNC into(on a single Server)? Then I can then leave them in different states for each project I am working on.
Here is another one.
Why Can't I take a program, pause it(swap it out)
generate a file of it's run state. Copy it across the net and resume execution right where it left off, but on a completely different computer? Or maybe after a reboot.. (HP had this years ago, or was it Tandem?)
I had some thoughts on this that I gave a talk on. It's missing much, and still not polished, but there are still a lot of good ideas in there.
Amorphous OS talk Sorry it's a powerpoint, but I know you Linux guys can still read it.
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
For instance, I installed Flash7 for Firefox 1.0. Didn't work. I installed Sun's JAVA for Firefox 1.0. It didn't work either.
I've installed both on several distributions. I have to tell the Flash installer where Mozilla and it handles the rest. For Java, I have to create a symbolic link to it in my Mozilla plugins directory. They both work fine, except that the sound and video get out of sync in Flash.
Small developers have to either open source or pay fees they cannot afford to obtain a "widget set", something that any other OS supplies for free, and defines a standard for.
Except for Qt, most do not require you to pay a fee or open source your app.
Linux has a pretty poor cache and swap system, combined with zero user level control over cache and swap. As a result, over time, the OS runs slower, and s l o w e r and s... l.... o..... w...... r....... until you restart,
I saw this mentioned in the Red Hat bugzilla, affecting RH9 and some RHEL3 users. But they say it was fixed mostly in 2.4.24 and completely in 2.6.
The GUI, in the user sense, is an afterthought. You have to go to the command line to configure and/or adjust and/or install many things.
Yeah, but I have to use the Windows command line for a lot of things, or dig around in the registry. People who can't on Windows get help from those who can. The actual amount of command line work necessary in Linux varies between distributions. I can do a lot more fron the Linux command line than from the Windows command line, so I'm more apt to use it.
So mostly, people don't run Linux.
But I'll always run it. Ubuntu is starting to look good. I'm running the unstable hoary hedgehog branch scheduled for release in about 4-5 months. Lots of nice things appear to be on the way.
They can't have children, obviously...
That is the typical problem I faced as a non-geek woman to get Linux installed on my machine. Firstly, the support system is mostly online and erratic to say the least. If I dont have my system setup and running properly how will i get help. Secondly, assuming one can get the answer reading tech 'help' files or online manuals is a fallacy best avoided. If the help files or manuals had all the answers why would i be posting a question online? Most of the S/W is CLI based and dont have GUI support. It is very scary for a non-geek to experiment with and expecting them to learn CLI commands for so many applications is such a waste of time since the *real work* never gets done and one is left poring over reams of tech material. Programmers/Designers please realise that its the end-user who will decide the popularity of software and if easy to use/learn software is not provided then he is not going to waste his time even if it is free.
The above is my currrent understanding of the LGPL, gleaned from postings responding to my questions on another site. If that understanding is correct, then anything that is LGPL'd is ruled out; closed source developers will rarely want to have anything to do with this, and for good reason, IMHO.
The point is the widgets should be part of the system. Not something the developer has to get, and certainly not something the user has to get, and not something that only works under kde or gnome -- they should just be there. They should be standard. They should work under all the desktops. They should place no requirements on the developer. Do you see any requirements to use a freaking file dialog in Windows? Seen any Windows applications that couldn't ship (or got recalled!) because the poor developers were bold enough to assume they could use a treeview control? A menu? Of course not. Because these things are:
Linux does seem to have a GUI problem that no current widget set that I am aware of solves, though I remain open to the possibility that one exists. It also has a licensing mentality problem -- the mindset shuts the door to closed source people, as I described above. What Linux needs is a decent standardized widget set that is in the core functionality. If someone ever gets that done, they'll be the person who facilitates Linux becoming a viable platform for a whole bunch more developers. A hero of sorts. LGPL and all that "you must do this, that, and the other thing to use this" stuff is fine, as long as you want to remain on the fringes. When Linux wants to become mainstream, it'll have to bring a GUI API into the mainstream, too. And it'll have to be 100% usable without tripping up developers, no matter how they want to wrap up their software.
I've fallen off your lawn, and I can't get up.
I can't believe this isn't at the top of the list. PRINTING. All Unix OS suck at printing especially with the low cost layer 2 printers. Solaris, BSD, IRIX, SCO Unix, all of them. Printing on Linux is okay.
Second what happens when you rm a file on Unix? Think you can get it back? As easily as reading the MFT on Windows systems? Think again....
Lastly ACLs.
How would I fix it. For printing and most drivers I would copy/R.E. the WDM and implement something like it.
Implement decent ACLs.
And provide an easier way to patch deleted files back together......
All the MicroKernel POSIX blather is just that blather!
In reading a lot of these, I see an overall trend to do a lot of OS comparison. Myself, I have experience with a lot of OS's, and I grew up using DOS, then OS/2, then Windows, then Linux. When I look at this, and what has come to dominate the desktop, I find that there are many, MANY good things in the current Linux distros, and *nix in general. There is also a lot of work left to be done.
/usr/bin and /etc, but much more complicated when things are split up). Apt, both for RPM and for DEB, is really good at solving dependencies, but I think a bigger problem involves people actually MAKING packages. For some reason developers not familiar with package managers hate making packages. Things like InstallAnywhere are starting to create the same problem that Windoze has, which is uncontrolled application installation and apps that are hard or nearly impossible to uninstall. What we need here is a GUI toolkit for developers that allows for quick package management. Imagine an app that a developer could plug in some basic info for, and it would compile a pacakage for multiple pacakage managers, and for multiple distros, and even versions of distros in some instances! I could then just post the packages, and then let MIME take care of installing them for me. If we have pacakage management that get stupid easy, we get a similar system to OSX or Linspire, where software installation is a snap. And as a community, I think we can find a way. I believe that none of these third-party app problems will exist if there is a a good package development tool and the distro vendors make plugins that will ensure that the resulting package makes the right symlinks, etc... for that distro.
UNIX distros, with the exception of OSX and some of the BSD's in general, suffer from one major problem: Age. HP/UX, AIX, Solaris, etc... are so stuck to the old tools that new ones must be reinvented from the ground up in their minds. The Solaris machines I've dealt are pretty much GNU/Solaris machines, since a lot of the basic admin tools I've replaced with GNU equivalents (how hard was it ever to add a -h flag to Solaris du or dh! Sheesh!). CDE is old and antiquated ( reminds me of being on Warp 3 again). I think this stems from the commerical and niche nature of those UNIXes, and that's why I think Linux is trumping them.
That being said, here's some of the problems that Linux needs to overcome to be easier to use for everyday joes:
1. The great desktop war: KDE is great, GNOME is great. However, many people have problems dealing with which one to develop for, and a lot of times which one to use. I've found that I love KDE's look and feel, but what we really need is a SIMPLE common API for developement, that then can get morphed by the desktop to look like that desktop. I know some work is being done towards this, and when it matures, what you will find is a basic toolkit for GUI development, and the KDE and GNOME toolkits will be extensions to allow for more advanced GUI work.
2. The filesystem layout war: I don't know how many times people have bashed the *nix filesystem layout. I'll tell you right now it's far, far better than a lot of other OS's out there right now. Although some ideas like directory contained applications is cool and has some other nifty applications (such as easy chrooting), we have package managers now, and I'll tell you right now that I've fallen in love with them. RPM and deb (NOT APT!) are both good tools for checking versioning information and determining where stuff is. This makes the filesystem layout less about where binaries and config files are, and more about disk placement and security (e.g. maybe I want somebody to run an application but not change it's config: easy to do with
3. Just simply more automation. We have all of these nice scripting languages, wouldn't it be nice if we hand these quick scripts to Joe blow and have them work? If I could put a very basic GUI on top of my tool without needing to know the in's and outs of GUI dev
For instance, I installed Flash7 for Firefox 1.0. (& it didn't work)
Sudo as root and run the installer from the command line. Worked for me, just did it last week. Of course, Ma Kettle will not know sudo from sumo but isn't that the price we pay for non root access? Not a troll, just the facts.
- Unix's IO systems don't have the facial/gesture/voice recognition systems that let me interact with it in the same way I interact with my dog or child. Input in this day of fast CPUs should be mostly done through video cameras and microphones. I should be able to say "hey, get the latest kernel and build it, if it has anything important to me", and the computer should know what applications I use, and go find out.
- Jobs (well, intellegent agents) can't easily move from my desktop (where they should be working while I'm asleep) to my Laptop (when I go to work) and to my cell phone (when I'm away from other cocmputers).
I'd have many other ideas - but most of them are more in the application side. I think commands like "drive to the store, get groceries, and make me a good dinner" would be useful -- but that seems more like an application build on top of the IO-system and job-migration features listed above.What I'm actually missing across the different versions of *NIX is interchangable device drivers. Maybe I missed that but there doesn't seem to be a common defined interface.
Compare the commercial Unices with Linux and tell me which one supports the most hardware?
Furthermore I'd like to see some principles of Plan9 in *NIX and Linux, but I believe the concepts are not compatible.
In Korea, all your base are Only For Old People
Give me OS X/ X86 or I'm gonna club this here baby seal! .app bundles are cool. code/library/config/resources scattered all over the hard drive is not.
.framework bundles for libs and header files) on many OSes, including Linux. See http://www.gnustep.org/
GNUstep does that (.app bundles for apps or
First they ignore you, then they laugh at you, then they fight you, then you win.
There are many issues with actual implementations, but that is a different thing. Unix(tm) is a concept. Linux, Solaris, AIX, HP/UX, *BSD, etc. are operating systems implementing said concept - in different ways.
Complaining about shortcomings in these implementations is very, very different from proposals for changing the concept itself.
In the same vein "what's wrong with cars?" is not a question about whether or not the brake pedal is a little too far left in your model X. Changing the concept of a car requires much more radical thought, going back to the basics of what it is you desire - personal transportation? Cargo movement? Cool engine sound and hot babes?
As an OS concept, Unix has stood the test of time, and there's nothing fundamentally wrong with it. Everything I've seen here so far is just incremental improvements of the actual implementations.
Real answers to the question should go along the lines of
So far, I love Unix to death, and I hope its implementations will get better and better. I'm also certain that Unix isn't the ultimate concept, but so far nobody has come up with a better one. As Hugh Daniels said (at HAL2001) "my [interstellar] spaceship won't be running Linux" - I doubt it would be running Unix.
Assorted stuff I do sometimes: Lemuria.org
There are four relevant parts to Unix:
When Ransom Love bought Unix on a lark (my IPO was so huge... look, I can buy Unix...), the value of the name except as a trophy dropped to nil.
The public domain code and it's functionality lives on in BSD where some find it useful. Perhaps one day this branch will prove as versatile as Linux, but I doubt it.
The proprietary code and its functionality nobody in their right mind would want, because "The Future is Open(R)(TM)".
The POSIX architecture has been reimplemented in Linux in a more consistent way than using most proprietary *nix wares, and in parallel the technology of operating systems have been advanced to support more advanced concepts.
Before the parts were rent asunder, they ruled the server room. Now they have been broken apart, and like humpty dumpty, they'll not be put together again.
Unix is dead.
Help stamp out iliturcy.
You don't ask a question directly; rather, you write something like "Linux sucks because it can't do X but Windows can.".
To use your USB mouse example, you probably went on a board or IRC somewhere and wrote:Note that you asked a reasonable question and thanked people in advance for their help.
This is a recipe for disaster.
The board gurus will pounce on you like a
Instead, you should have written something like:You will have Linux gurus crawling out of the woodwork to show you that, yes, Linux does support a USB mouse, and the reason you couldn't get it to work was probably one of the following: X, Y, or Z, and here is how to work around or fix the problem, and here is where you can find additional information, and here is where you can get drivers or other needed software, or a more user-friendly front end, etc., etc.
Note that their attitude will be as snotty (or snottier) as with the nice method of asking, but you will get the information that you require.
Note to mods: The above may appear to be flamebait or an attempt at humor, but this method actually works.
Try it!
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Great system, shit user interface. Maybe they can learn something from this.
I'll just mention that these same issues were handled quite well in NeXTSTEP.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Installing software is highly unreliable, non-standard, a maze of twisty little interdependant passages, and deeply obscure.
Really?
For the end-user, it's as simple as an apt-get, rpm or emerge command (or whatever package manager you use).
Ah, you're talking about the developer? About installing software that is not packaged? Well, try that on windos. Come back when you're done, like 2006 or so.
There is no standard "windowing" GUI
Which is a huge advantage.
I happen to hate the XP/windos standard GUI, and there's nothing I can do about it. I tried a few replacements, they all suck, are incomplete, break the system or simply don't work because the friggin GUI is so tied into the OS kernel.
On Unix, you can choose which GUI suits you best. I prefer to choose myself instead of having some marketing monkey in Redmond make my choices for me.
Linux has a pretty poor cache and swap system, combined with zero user level control over cache and swap. As a result, over time, the OS runs slower, and s l o w e r and s... l.... o..... w...... r....... until you restart,
Troll
tom@nox:~$ uptime
10:04:32 up 132 days, 17:49, 3 users, load average: 0.08, 0.06, 0.07
tom@lemuria:~$ uptime
10:00:18 up 156 days, 2:00, 1 user, load average: 0.02, 0.03, 0.00
tom@Mandor:~$ uptime
10:02:44 up 31 days, 21:01, 1 user, load average: 0.02, 0.01, 0.00
All of these are systems that are in constant use as desktop (nox) or servers (lemuria and Mandor). They're very snappy. I've driven one of them (nox) close to the thrashing point once, brought it back and it's been running well ever since, without a reboot.
You, my friend, have fucked up your system, that's all. Don't blame it on the machine.
Oh, and it's a very, very good thing that regular users have no control over cache and swap. If you don't grasp the security and reliability dangers inherent in giving them that control, you should give back your root access.
The GUI, in the user sense, is an afterthought. You have to go to the command line to configure and/or adjust and/or install many things.
Again, this is a strength, not a weakness. When your GUI breaks on windos, OS X or any other GUI-only system, you're fucked. On Linux, I can drop to the commandline and within a minute or two everything is running fine again. Sure, it may not really be faster than a reboot, but if you have stuff running in the background, then you don't really want to reboot.
Assorted stuff I do sometimes: Lemuria.org
Likewise not standardising some basic data-interchange formats (Even it was just pre-formated ASCII)...
...ALL use the same, consistent, universal plain text format everywhere, in every language. All characters, all the time, in all applications, on all forms of *nix.
Define the standard *nix system text encoding to be UTF-8. Require every tool to assume UTF-8 when no encoding or other modifiers are specified, and make UTF-8 support a requirement for every tool that wants to participate in the chaining/piping operations that are the backbone of *nix.
Terminal programs, terminal servers, shells, system fonts, cut/copy/paste, file system, GUIs, editors,
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Just a reeminder, Linux is NOT *nix. Linux is a kernel.
As for fixing it? I dunno, maybe an unsigned integer, or a 64bit signed integer for 64bit flavours?
Joel Spolsky has probably done the best job I've seen of explaining What's Wrong with Unix.
Ergonomica Auctorita Illico!
The GP was responding to the GGP's complaint that all of that crap should have been in there from the beginning.
Given the limited hardware of the time, it is incredible the amount of stuff that they were able to put into the system while keeping the user/kernel interface clean and simple.
Yes, ACLs and the like should be in Linux now, and they are to some extent, but to say that they should have been in there from the beginning is a completely ignorant statement.
And the "stupid motherfucking unappreciative asshole" bit in the subject line is because the "grandpas" were the ones that wrote UNIX et al.
Linux wouldn't even exist today if it weren't for them.
So shut the fuck up.
Linux already has this - it's called Access Control lists. From a SuSE manual I found in 30 seconds with Google:
ACLs can be used for situations where the traditional file permission concept is insufficient. They allow the assignment of permissions to individual users. Access Control Lists are a feature of the Linux kernel and are currently supported by ReiserFS, Ext2, Ext3, JFS, and XFS.
Back off the tangent to the thread - the eliteist attitude of *nix shows in so many ways, and it hurts widespread adoption, which is to its ultimate detriment. Auntie M may think a boot screen that says "GRUB" in plain text is funny, and slightly disturbing - leading her to choose the more "normal" operating system. Try selling your mainstream boss a development environment supported by some Scandanavian guys who call themselves Trolltech... all these little attitude statements add up to keep the rebels on the fringes of the galaxy.
In what way are names like Oracle, Microsoft or Peoplesoft better? Because they have a NY stock symbol attached to them?
"Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
Their license
I`m a newb in Linux, and I don`t generally use it too much. Although I like the idea of linux, there are some things that put me off it. First one is, ofcourse, that "everything" first-class, as far as a simple user goes, is released on Windows. On Win I can jump from compressing a movie to XviD with Gordian Knot to playing HalfLife2, to hearing MP3s while working in Photoshop and compressing with WinRAR and downloading with eMule at the same time, just by doing 5-6 clicks of a button. On linux, to do the same, you need to type. A lot. To avoid that, you have to create scripts, wich again means that at sime time you have to type. A lot. Linux ISN`T "user friendly" by design, and that hurst it. Two things that anoy me the most are firstly its idiotic file / directory structure, where when you install a program / application it goes all over the place and you have to search for its individual files (thats how I understood it - if it isn`t this way, sorry, but it wasn`t as obvious as it probbably should be) if you want to check something out. Take for example aMule. It installs its main files in one place, its preferences / user setup in another, its temp, down and shared dirs in some completely diferent place. Nice? I think not. The second thing that is quite annoying is, again, its user friendliness as long as error tollerance goes. Take X for example. I change my ATi card to an nVidia one. What happens? "Cannot start X". Ok, but we`re in 2005. Can`t you, at least, select a generic VGA and start the damn thing? Or even an EGA and show me a basic graphic environment, where I can at least search on the Internet for some help in some clear and usable way? No. "Cannot start X". You have to start a console-based browser and hotkey your way to google, searching among heaps of text for some help. Niiiice... Change these two at first, and you`ve got a winner. Make it possible that each and every program installs everything into ONE dir, with links to other dirs, or if that happens (told you, dunno, I`m a newb) show the user that it actually happens that way. Show him how he can manage files. Give him a proper file handling tool (Nautilus? Yeah, right...) like Directory Opus on the Amiga, or its spinoff for Windows (Gentoo - the file manager - tries to imitate this but actually is still miles away from them). Use DEFAULTS, for crying out loud, for X, and mPlayer, and anything that could crap out and fall on its face reporting that its misconfigured. Supply a ready, basic config from the start for each and everything on linux. And try to avoid behaviour such as mPlayers, where when you start the program and throw a file at it it shows you an interface, but when you double click a video file it starts without one - where the heck is it hidden? Do these sound as newbie questions? They are. They are what makes me avoid linux when I don`t have a lot of spare time to spend on it and revert to the all-easy Windows. And do you know something? I don`t care if linux zealots don`t care about people like me. They lose as much as I do. They won`t help me out because my needs are silly for them, I won`t design some graphics for them since I simply cannot work on what they provide me. Best Regards Ducklord
Unix, and really any software platform, could really benefit by two things:
What concerns me the most about such a question is that we'll first have to try to assess which Unix Fixes are being proposed not to really fix anything that's wrong with the OS, but just to change it for the sake of changing it.
Not being a noob or anything like that, but I still wonder why should the operating system be case sensitive ? Any religious reason for that ? If you are talking about Linux's (if I could use that as an example for *nixes) usage in the mainstream, try explaining to an end-user that MyMail and mymail are different files.
Without the actual evidence that I've got servers running Linux (2.4 kernel series) that have 400+ day uptimes and are running just as fast as the day they booted, this is patently untrue with the 2.6 kernel series. The swappiness of the system is easily set (/proc/sys/vm/swappiness) from a range of 0 (never swap) to 100 (agressively try and swap pages out). The default is 60. Even with the 2.4 kernel series and older you've been able to turn swap off, add swap, remove swap space without needing a reboot.
Distros such as Fedora Core (and I assume RH's commercial distros) even have a GUI tool for adjusting these parameters.
Oolite: Elite-like game. For Mac, Linux and Windows
Granted, servers rarely, if ever, swap out. But my desktop has been linux-only for some years now and I have never observed the behaviour you describe.
If at first you don't succeed, skydiving is not for you
god n. : the Supreme Being, indistinguishable from a good random number generator.
Your complaint is valid in the sense that there are many tasks that can't be done through the GUI, but only through the lower level (design-wise) command line interface. That's the result of being an incomplete system. This is very different from being the result of an ill-designed system.
If at first you don't succeed, skydiving is not for you
Now this touches the Path For *Ix: Make it to operate on a mouse only (apart from proper names). Wonders can do it. OSX can do it. *Ix can't.
BTW:
-Interesting = false
-Informative = refuting parent
-Insightful = changing topic
Pay attention. C++ ABI incompatabilities were fixed with the release of GCC 3.0, where G++ now uses the standardised Cross Vendor C++ ABI.
for this comment.
No, seriously... 5% of population are geeks in the sense that they can understand and follow instructions regarding their machine. 1% are ultra-geeks that could write a little program or script or compile something from source. 95% are the Joes and Maries that use the machine and call support/neighbor/relative if anything happens. Like don't print or so.
That explains all about percentages of desktop OSes. Requires command-line? Just lost the other 95%.
--Quality of trolling lacking lately--
I really wonder about this. Is it genetic? Is it a personality fault tied to technical ability a la Asberger(sp) syndrome?
-jpeg
This is funny as all git-out. Makes a guy feel nostalgic.
I remember reading all these same arguments - the very same ones - back in 1996 on comp.os.linux.advocacy. "No standard GUI." "Hobbyist OS." "No standard widget set." "If you want to be taken seriously, you're going to have to be a clone of Windows." "If you want users, Linux will have to be a drop in replacement for Windows." "No serious developer wants to have anything to do with the GPL - BSD everything!" "A computer should be as easy to use as a toaster; I don't want to have to know how the computer works in order to use it!"
And my favorite..
"When Windows 98 comes out, Linux will be history. People are only trying Linux because they're tired of Windows 95 crashing."
I even remember a coworker telling me in 1997 that Linux would never reach the enterprise, because no one would trust their business to an OS written by volunteers.. and if it ever got to that point, Microsoft would simply crush it.
Or "buy it out". I always loved that one.
Folks, please, grow up. Like it or not, the free software and Open Source movements have significantly reshaped the computing world. They will continue to do so, which means that we will progressively move to a computing society based on consensus rather than dictation. If more options, GUI's, licenses, widgets, filesystems, even operating systems makes you feel uncomfortable.. well, you're just going to have to cope, adapt, and learn new things. Sometimes simplicity isn't a good thing.
Welcome to the world of grown-ups.
Darl McBride!
Cut it out with the uptimes. Anecdotal evidence doesn't mean a thing. Just because you aren't experiencing the problem doesn't mean that it doesn't exist.
You, my friend, have fucked up your system, that's all. Don't blame it on the machine.
Could it not be said that the ability to screw up the system so badly is the fault of the system? That's the thinking that is applied to Windows, but when Linux screws up, it must be the user's fault? Ridiculous.
The 'everything is a file' concept is great in general but needs to be expanded a bit to make everything work transparently over the network. X permits accessing programs from different machines but doesn't really encourage it: none of the common window managers provide ways for programs on remote machines to add themselves to your menus and there is no way to tell a remote application to use your local view of the filesystem. This design is left over from the day when networks were slow and no one could afford more than one computer. Now it would make much more sense to be able to be able to add 'building-block' resources (fast CPUs, file storage, removable media, etc.) independently in incremental upgrades by dropping them on the network and being able to use them as needed from anywhere.
Someone should start over with a design that assumes that there are more computers than users and that each user wants to take advantage of some nearby peripherals and share some others. Unix is a better start than Windows or OS X, but nothing gets the concept quite right yet. Mosix 'kind-of' has the right idea, but you probably really only want your processes to run on your own workstation or a designated set of servers. You don't want them to run on someone else's workstation where they might accidentally hit the power button and lose your work.
Virutal Memory when used by amatuer software engineers can be a disaster.
Swapping of large objects back and forth from the harddrive to the memory results in thrashing and can bring performance to a halt.
The virtual memory system is on the things wrong with Unix/Linux
on PCL sucks.
PostScript is device independent, within the limitations of the printer, output from a $100 inkjet will be close to output from a $400,000 laser press. PCL has different codes depending upon what printer you're printing to, mostly for paper selection, but it can be for other things.
PCL has laughable color. PostScript supports Pantone colors, so the flyer you proof in Baltimore will look exactly like the production run in Chicago. PostScript supports CMYK colors, and RGB colors.
If you ever get a chance to walk into a print shop, you'll have to search high and low for a PCL printer, whereas everything else (the proof printer, the plate setters and the laser presses) use PostScript.
Fix Unix who? I hate it when people only use first names. Besides I thought I heard that Unix whoever was dead! How can you fix someone who is dead? Bury them again? Would someone please ask Mr. Linux, Unix's son I believe, what his dad's first name was? We need to fill out the gravestone properly you see. ;)
SELinux deals with port permissions.
I don't know a lot about it, but it seems to answer the concerns that you have about ports and users.
This sounds more like a question to see what kind of mind is running inside the person. If their complaint is something general and whiney, like "its too complicated", "its too hard to learn", or something like that, then they're probably not very smart, and don't like to learn. Thank them for their time.
If their complaint is specific to a type of UNIX, and is technical in its nature, then you at least know what kind of UNIX they are familiar with, and you have some info about how technically savvy they might be. Nit picky though they might be, they are probably thorough. Try to find out out irritating they are before hiring.
If they compare strengths and weakness of several strains of UNIX, they are probably experienced, curious, smart, and like to learn. Hire at once.
If they say how great windows is or how UNIX isn't the 'industry standard', they are brain damaged and likely a threat to society. Push button to open trap door beneath applicant. Listen for cries of horror
I used to think user-friendliness (btw, not unix, linux), but dammit if it doesn't get easier every day. I still think it's a little inaccessible to your average bear. And person.
Whenever I talk to my girlfriend about computers I find myself having to do things like explain what RAM actually IS. And folder hierarchies. But this is in general wrong with all computers.
Windows's implementation of virtual files (My Computer, My Documents, etc) sucks, sucks, sucks, but it's on the right track as far as GUIs go. And I'm not a GUI nazi either. I'm just saying that the *nix GUI layer is a little immature.
Which I guess isn't really anything wrong with Unix, since it pretty much does what you want it to do when you want it to do it. My point I guess is that the whole desktop workstation environment isn't quite there yet.
On proofreading I've found I'm a terrible waffler. Oh well.
Please stop stalking me, bro.
There are severe problems with the virtual memory system in Linux for very large objects (megabyte) and no way to control it unless you install real-time extentions. There is no way to say (that I know of) 'don't swap this object, it wants to stay in memory' for generic Linux without realtime extensions.
Fortunately these only show up if you are doing real-time systems and you have idiots instead of software engineers designing your code.
I agree that linux memory management is actually pretty decent, however, if you are doing real-time processes you really want the real-time extensions for Linux. Or, make sure you don't have amatuers on your software engineering team.
Unfortunately anyone who ever wrote a script or typed make install is classified by headhunters as a software engineer.Sir, you've replied to the wrong post.
You must be kidding, right? Observe the following chain for printing a pdf on Linux.
pdftops -> pstops -> pstoraster -> rastertoips -> usb -> printerdriver -> unknown conversions -> printed page
That's five conversions, at least, for a single printed page. Document printing takes a long time to start and a longer time to complete.
Using Windows on the same system to print the same page, printing starts immediately. Printing is ten or more times faster than above. Far less conversion takes place:
pdf to pcl -> usb -> printerdriver -> printed page.
Add to this that PCL is supported on virtually every printer. Postscript printers are less common today.
Gnu's Not Unix
There are two main problems which tend to block mainstream acceptance.
1) Case Sensitive Filesystem. Tech Elites understand that A != a. Nobody else gets it. Sure, they "understand" that A isn't the same as a, but why can't the computer see the file when I type a?
Using a case-insensitive filesystem is one of the first, easiest and most important concessions an OS author makes to DWIM (do what I mean). This involves changing the kernel (e.g. http://bill.herrin.us/freebies/ ) and then recompiling the apps like the shell and find so that they understand the filesystem may be case insensitive.
2) X-Windows. The unix architecture in general has held up remarkably well over time. X-Windows has not. Its overweight, difficult to program for, and slow. It should be replaced from the ground up with a graphics system designed to be a modern desktop gamer's system.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
The CDROM filesystem should be treated differently. It should not lock the CDROM into the machine.
If you read through the discussions you see a trend where this or that is missing from the core but it is available as an addon. Everything is there and documented but you have first know what you are looking for and then find it and install and configure it.
No one solution is right for everyone so there is much fragmentation and LOTS of features that are completely customizable. That is what is both wrong and right. And then you have the ever increaseing revisions which have an amazing amount of dependancies. Which again is both what is wron and what is right.
You can not have your FOSS and eat it too. It is this way by design.
People have fixed symptoms of deeper problems, and now the operating system is so patched up that it's almost impossible to make the sweeping changes we should have originally made.
One case in point, filing system journaling was not existant, so a common method was to save to a new file, and then issue a command to the filing system to overwrite the old file with the one you just saved once the file is written to disk.
This sounds fine, but then you realise that none of your old editors preserve ACL's. The same issue I believe can cause problems in some journaling systems.
The problem is, we fixed all the problems the wrong way.
Non-Technical End Users please realize there are different User Types out there and not every Software has to be tailored to your needs. There is enough Software out there perfectly usable by Non-Technical End Users not willing to learn something about Computers and most of us Technical Users don't see the reason for changing all of our Software to fit your needs.
Linux is not Windows
Yes. Because of that and because they're not "cute" or "queer" names that the 90% of people referenced elsewhere in this thread recognize and more importantly, trust to run their businesses on. Business drives adoption for the majority of technolgy, despite whether computer nerds like it or not. Technology without a marketable application AND ease of use has a hard time getting used.
It certainly has been on the big iron I've played with over the years. Why can't Unix do the same?
There are many reasons why some classes of businesses continue to use mainframes heavily, and a lack of robustness on the operating system level is a very large part of the reason. It ain't all about CPU, folks...
Some Unix people really *do* need to learn from non-Unix computing history, at least in this programmer's opinion...
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
After reading all the comments and being a linux user for over 10 years now. I'd have to say the problem with Unix (on the linux side) is the perspective of the application developers. For instance all the complaints about filesystem hierarchy and installation standards come because of one very simple reason. The developers leave package managment up to the distributor. Developers of an application by and large don't bother to come up with an cross platform installation for their app. Consequently the distro's come up with their own. If KDE and Gnome had a downloadable install that worked on every system and worked the same way then you would have standardization across distro's. The same thing goes for upgrading. Applications would be able to upgrade across platforms. Ditto for uninstalls. when Each distro does it a different way it becomes unmanageable. It should really be the developers responsiblity to handle installing the application not the distributors. Until developers take responsibility for managing their installs the problem will be difficult to fix. They are the only ones in a real position to set a standard for their app.
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
I am sure it is grown up now, but those of us who were exposed to it 10 years ago are going to treat it like a city park built on top of a radioactive landfill. That one looks much friendlier, I will admit.
I prefer Safari. In fact, wikipedia is turning into a very useful resource for getting answers. In any case, now that the web has matured, obtaining answers is not all that difficult anymore.
The UNIX community does have a barrior of entry and still does to some extent bootstrapping n00bs. Someone coming into the community, and wanting to learn about it has no idea at first where the documents even are. RTFM can be countered with WTFITFM (Where The Fuck Is the Fucking Manual)?
Linux actually gets faster the longer your system has been running. This is due to filesystem caching. My desktop workstation has the most recently used 3GB of files cached in RAM, which makes for some impressive "filesystem" performance. Sure, if I loaded a memory hog application the system would swap out some of the cached files (which would take some time), but overall the performance of the system is enhanced by the swapping/caching regime that Linux uses.
Also, you can adjust the swappiness parameter if you want to always keep a certain percentage of RAM free for programs that you might want to open.
This stuff all works extremely well in Kernel 2.6. If you are using an older kernel you may not be benefitting from all of the latest enhancements to the vm system.
Also, if you want to see what the current state of the art is in Linux, try Gnome with Ximian, OpenOffice, etc. It's not as seamless as Windows XP in terms of an easily configurable user experience, but it's getting extremely close.
Amazing magic tricks
linux/unix bloat is the main problem.
...)
Take processing a file for example:
a. There is no automatic way for the OS to determine the application needed to process a file (e.g. troff, ps, awk, php, perl, shell, tcl,
b. There is no front end to narrow down the series of steps needed to process a file. For example, find and replace all 'ABC' strings with 'DEF'.
c. There is no end user front end to find the documentation related to a given task. Man -k does not help enough.
Indeed. I read your post as "just boot in single user mode..." and immediately hit "reply" and completely glossed over the CD part. My apologies. But yes, you're correct:booting from the CD in single user mode should work, assuming diskutil and the necessary filesystem support is present in /System/Library/Filesystems on the CD itself, and it appears that it is (at least on the 10.3.5 CD I'm looking at).
Without a package manager, it's practically impossible to remove a program.
I think this presents another point in that when you figure out how to remove a package, it's difficult to determine all of the dependencies that needed to be installed to support the original package. You may have had to install several dependencies, and now not only do you not remember what these were, but you also don't know if other packages you've installed since then require those dependencies. You then end up with a bunch of random packages on your system that may or may not be needed. This is particularly a problem when testing several packages of the same type in order to determine which package is right for you. It's not always practical or feasible to have a separate development system for this kind of testing purpose (which could be argued as another problem in itself).
My faith in the UW system (I'm a UW-Milwaukee alum) has now been restored. :-)
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
To some extent this is because people are too reverent towards the core of Unix -- it's as if the stat and inode structures are sacred relics which mustn't be touched. But that's nonsense: Unix is a hacker's system, so if those structures need to be augmented, they should be!
There's work being done in this area, of course, but someone needs to step forward and put a big stick in the ground saying "this is an attribute filesystem and API to it that everyone can and ought to use to centralize file-related metainfo."
How many data points does it take to go from being anecdotal evidence to statistical average?
I have been using Linux for 6 years. I haven't seen what your are describing regarding the slow down of the system.
Just a Tuna in the Sea of Life
Yes, I have. That's why I mentioned it as a "where people will go" for ease of use. I think OS X is a lovely thing. I wish Apple the best. If they can build a certain degree more market penetration, I intend to create a division to port our software there. We've talked about it a number of times, and we get requests to port to the Mac every day. We do lots of things Photoshop doesn't, so the market is open to us.
It may be that Apple has taken exactly the right steps here, the very ones I argue for. We'll see. The thing is, I owe the Linux community a debt; I don't owe Apple anything, as far as I know. :)
I've fallen off your lawn, and I can't get up.
I disagree with your moderation (as usual) -- I don't think you're trolling, rather I think the moderator was flaming -- but I do think you are mistaken. The LGPL has some issues which I have expanded upon elsewhere in the thread that present some problems. Please feel free to argue the point, or prove me wrong, where I go into more detail. I read at -1, so your moderation is irrelevant to me other than to emphasize slashdot's serious moderation problems. :)
I've fallen off your lawn, and I can't get up.
I'll say it again: Just because you personally aren't experiencing the problem doesn't mean that it doesn't exist.
We're not talking about averages here. An average doesn't tell you anything about the data except for its average. Yes, Linux, on average, does not have this problem. To be frank, I've never heard of Linux having this issue before reading the GP. However, that does not tell us whether the problem does or does not exist. You cannot prove a negative. We can (probably rightly) assume that the GP is lying or has an otherwise unusual situation, but then we're making assumptions, and we all know where that can lead...
Nothing personal. I just hate seeing people make absolute statements based on anecdotes, assumptions and guesses.
If we reboot our servers, web pages are served much faster than when they've been running for a while. After watching the situation for many months, I figured out when it happens - it happens when memory fills up and the machines begin to swap.
Potential reasons seem to be that it is faster to read a web page off the disk than it is to recover it from cache, or swap, once it gets stuck in there, or else it takes longer to free up the memory to put it in when memory is otherwise full of cached stuff.
Without being able to articulate exactly what is causing the problem, I can easily demonstrate the solution. After our servers have been running for about two days, you can go and fetch a large page of stuff into a web browser and observe how long it takes over a 100 mb connection -- it's not all that fast, it might take 2-3 seconds. Then you can reboot the machine that is hosting that page, and grab the same web page when memory is essentially uncomitted, all "brand new." The page will whip up in front of you -- basically, it is immediate, just a fraction of a second, which is what you should expect from the machines in question which have 3 GHz cpus and fast drives. This behaviour continues for a couple days (these machines also have several gigs of ram) and then it slows down. It is difficult to see the slowdown, so I am pretty sure it is cumulative; but it is very, very easy to see the speedup, and that's why I am certain that the problem is real.
It may well be that a later version of Linux has solved the problem. However, it is no small matter for us to move to a different version; we have a lot of operations depending on these systems. Reboots aren't that much of a problem, we schedule them for the off-peak minimums. The reason I mentioned it at all was because since you don't have to reboot, users might accept this sluggishness without realizing that a temporary cure is just a shutdown away, and because my 2 GHz Windows desktop machine feels snappier than my 3 GHz linux desktop machine. For instance, my graphics software loads in a fraction of a second under Windows. The Gimp takes much longer to start up, and it is a lot smaller and less-featured app running on a faster machine.
I have wished many times for the ability to simply turn off swap, and to prevent things like web pages and database tables from being cached. These machines are so fast for the first few days, it is really annoying to see them acting sluggish with all those resources installed. We have had no luck finding any solution to the problem (other than rebooting) as yet.
I've fallen off your lawn, and I can't get up.
Our software routinely manages objects -- images -- that are hundreds of megabytes. Layered images may have multiple objects that size.
About the very last thing you want to happen from the perspective of operating on it is have an image put into swap. It shouldn't happen unless it has to happen, and (for instance) having a ton of tiny web pages or database requests cached in memory is a darned poor reason to cripple up an image processing application being operated by the system's primary human user. But without any control over system cache and swap behaviour, you will run into these problems.
As a real world example, if you open up the Gimp and try to edit a large (but still easily fits-in-installed-memory multiple times) image on one of our servers that has been running for a couple of days or longer, it'll feel like you're trying to walk through molasses. If you do the same thing on my freshly booted desktop, same OS version, same resources, it'll be smooth as butter.
We're talking about machines that have 3 GHz CPUs and a minimum of two gigs of ram. It should feel "like buttuh"!
OTOH, My windows machine has a 2 GHz, 1 gig ram configuration; editing the same image there after the machine has been up for weeks (when it stays up that long... @#@$@# windows) is just as snappy as after you first boot. Application startup is even faster than at first, because Windows is a lot smarter about how it caches certain things; DLLs generally don't unload so you don't pay in time for each instance of application use, but stuff like images loaded off the HD don't cache at all the way we have our machines set up.
I'm not just mindlessly bashing Linux here. I like Linux. These are my experiences I am relating. I'm wide open to suggestions as to how to improve those experiences.
I've fallen off your lawn, and I can't get up.
Can you provide me with a specific pointer to the indication of the fix? I would very much appreciate it.
I've fallen off your lawn, and I can't get up.
Two things. One, there's mlock to do exactly what you want as far as not swapping out memory. Two, there are real-time extensions available to linux as patches (there's two different branches, as I recall; one open source and one not; the second one is legal because the patching and compiling is done on the end user machine). So, I'm really not sure the problem.
I've fallen off your lawn, and I can't get up.
We're running 2.4.20-6; would you care to share the mechanism of how to turn swap on and off in this OS level release? I would very much appreciate it. There is nothing called "swappiness" in /proc/sys/vm. I just looked for it. I show the following:
bdflush
kswapd
max-readahead
max_map_count
min-readahead
overcommit_memory
page-cluster
pagetable_cache
All are zero size, all show the directory read date and time.
I've fallen off your lawn, and I can't get up.
If you're doing Real Time work, wouldn't it be better to use a proper Real Time OS, such as VxWorks or QNX? Why would you choose Linux?
Stick Men
Asperger's Syndrome is a part of the Autistic 'Spectrum' (which is actually more of a mesh) and was discovered by Hans Asperger to be a seperate condition in its own right.
;).
What we now know as Asperger's Syndrome was previously thought to be a form of PDD-NOS (Pervasive Development Disorder - Not Otherwise Specified).
Hans showed by experiment that a group of children he was working with exposed a particular set of symptoms which were categorically different and it was seen to require its own 'label'.
Asperger's Syndrome often (you said often, frequently... no, I said often only once..</Gilbert and Sullivan - 'Modern Major General'>) involves obsessive behaviour such as the propensity to learn all of the rules of a structure (for example, the grammar of the English language or that of the high-level language, 'C') or to spend all day humming the same tune whilst tapping a spoon against the desk stapler
This is usually coupled with an inability to empathise with others which can result in a certain level of social ineptitude, although coping strategies can be put into place (or formed by the person in question) in order to handle common situations, upon which a further framework can be constructed, although I wouldn't refer to it as a "personality fault".
For reference, I am registered disabled as having Asperger's Syndrome and you can find me in freenode's #debian regularly (although I might not be around at the time) under the pseudonym of SquareRt, due to the fact that any nickname with "Root" in is (or, at least, was when I joined #debian originally) automatically banned when joining the room.
You can also find me on irc.nixhelp.org using the nickname SquareRoot in channel #linux. Other freenode channels I've been seen in include #squid, #sparc, #solaris, #debian-boot, #sgi, #wireless, #cisco, #madwifi, #math and #postfix, in no particular order.
I've been using Debian GNU/Linux for at least three years now and I look forward to talking to anyone who didn't die of boredom before reaching the end of this post.
I hope this post is considered on-topic, I've tried my best... I'll keep an eye out for replies for a little while but I may have to go for a spot of supper and some earl grey in a bit.
Regards,
TheScienceKid (611371).
Sorry, nothing much here... awfully sorry to follow up to my own post; I was simply correcting the omission of my presence in freenode's #irix at times.
Ciao.
Which is a huge advantage.
For geeks like you and me, sure. But not to ordinary folks who just want to use it--especially not when they need tech support. They don't need extra questions like, "Are you using KDE or Gnome?" Half the time, they don't even know they're using Windows vs. Linux vs. MacOS. Having a single, standardized GUI can help a LOT.
Linux has gone one way with this--diversity--and MacOS has gone the other--standardization. In my mind, what is needed is the happy medium: customizability--even if it's hidden away behind an "Advanced..." button on one of the control panels or preference panes. This avoids both traps: including too much choice, which is unnecessarily confusing to the normal users, while still allowing people who want to change things to suit themselves to do so.
When your GUI breaks on windos, OS X or any other GUI-only system, you're fucked.
Beg pardon, but Mac OS X has a CLI much like Linux (or, more closely, *BSD). Granted, if you truly have no GUI interaction going on, you have to SSH in, but it is there, and just as functional. I've used it to rescue a locked box many times.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
... you insensitive clod ;)... and I can't stand BICs or other ballpoint pens, although parker rollerballs are bearable, they're nowhere near as effortless as a good fountain pen... you... BIC user ;)
Ciao,
611371.
I think Red Hat is up to only 2.4.21. They backport a lot of patches though. The bug report I originally found applied to Red Hat 9, and was marked Closed WontFix because Red Hat had discontinued support for 9. Some fixes and patches were suggested. I also found a Fedora Core bug report that ended saying the problem was greatly lessened in 2.4.24 and fixed in 2.6.6.
I just found this RHEL3 bug report which states that the bug has very recently been patched.
If none of that helps, maybe you could make a cron job to empty the cache every hour or so.
I myself think printing is one of the fundamentals
"Print is dead." -- Egon Spengler
Five percent of one year's DoD budget puts us on Mars.
I still think that to win a market share, the most important thing is to have a good product. Microsoft had a cheap, not-so-bad product in the past and that's how it got where it is now. I have no doubts that were it called Trolltech, its success would still be as it were.
"Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
Thanks for the help, btw -- very much appreciated (and a very nice change from the hysterical "There is no such problem, you trolling b*stard" responses", too. :)
I've fallen off your lawn, and I can't get up.
I don't uppgrade the Mozilla applications that often, but everytime I do I wonder how much code is shared between Firefox and Thunderbird? I would rather have more common updates to several small packages than having to download two large package when common code is updated.
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
While I agree with the rest of your post, Microkernels aren't about modularity. What are microkernels? kernels that delegate work to user land. Windows NT 3.51 had a 'micro'er kernel than the current versions of NT for example, in that the GDI was a usermode service. This proved to be so slow that they moved back the GDI into kernel mode. From a coding perspective, the GDI is still modular, it's just that it runs at a different priviledge level, effectively alleviating the need for context switches.
As a general rule though, microkernels are problematic not because of their speed, but rather because of the advantage of having a microkernel.
For example: if you put your filesystems in a user mode service and this service crashes, you have effectively lost track of any open file handle on the system, which is still up and running because the kernel itself wasn't affected. Problem is: the system is now completely useless. In fact, the system is in a far worse state than if it just simply had BSOD'd or kernel panicked. Why? Because applications won't be aware that half of their resources have just been sucked out from underneath them. For example: imagine a daemon of some sort that when it receives a socket transmission, sends back a response and writes something to a file. Now, it will send a response, but fail the file write, effectively violating application level state rules.
Excuse me, I really need to go off and chuckle for a while. Thanks for the absurdity. :)
I've fallen off your lawn, and I can't get up.
I think that in this context, that is a distinction without a difference. I would contend that something needs to be done about it, and finger pointing as to what the cause is doesn't get anything useful accomplished. If it's broke, fix it. If it is unfinished, finish it. Same result either way. The problem is no less of a problem to the end user no matter what the nature of its cause, and it is no less of benefit if it is made to work through a fix or additional work.
I've fallen off your lawn, and I can't get up.
Perhaps yours does that very thing. Mine doesn't. It would appear, from (so far) unconfirmed but authoritative seeming information in the other posts, that my problem is documented and that in order to resolve it, I may need to change the OS level. I have no swappiness parameter to adjust, or at least, if I do, it remains unidentified at this point in time.
Also, I am a gnome / open office user. I'm pretty happy with that level of experience, or at least I will be when the OO 2.0 database UI creator comes out. I use some of the tools every day. In several languages. Very nice indeed. When we port our image manipulation tools to Linux, I'll probably be able to stay on Linux most of the time, which I look forward to. But that's not to say that there aren't improvements that could be made. :)
I've fallen off your lawn, and I can't get up.
KDE 3.2.x does exactly this
log out
ctrl + alt + bksp
log in
restart software
yay fast for 4 more days......
ksystemguard tells me when to much is swapped out...
but it's not linux , it's memory leaks in software that can be restarted!
Type unto others as you would have them type unto you.
yea like excel is a normal name related to what the software does.
points of view happen because you are standing somewhere looking at somewhere else.
Type unto others as you would have them type unto you.
Ah... empty the cache? Do you mean by trying to use all or most of memory with something, or do you know of some magic thing I can do that will dump all the currently cached stuff?
/proc/sys/vm/swappiness
I didn't bother to see if there was an easy way. I've never dealt with swap and cache problems in Linux. We haven't noticed any performance problems on our file servers running Samba on CentOS, a RHEL3 clone, and we only reboot them to update the kernel.
I haven't tested, but this should have the desired effect of forcing programs back into memory:
swapoff -a
swapon -a
Bad things might happen if there's not enough ram to swap in all the programs.
In 2.6 you can tune the swappiness by echoing a number from 0 to 100 to
Then I did the swapoff -a. It took about a minute to complete; I was getting nervous, frankly. Then it came back.
Cache level changed a little, but not much. I went to open a program. BAM! Thing was right there, just instantly. Tried another. Same result. Only... now there is less memory in cache. I guess it got forced out by loading the programs. Next I tried some web pages, going direct to the server. Again, BAM. They're fast like on first reboot. Windows drag live - just like they are supposed to.
Something else. On the toolbar, I keep graphs going of memory, swap, network and cpu. Just a little Gnome graph thingamazoid. The typical behaviour has been that memory fills up, and once it does, it doesn't change much, if at all. Now, after the swapoff -a, I can see the levels change when I do things like prod the shopping carts, look at the software revisions database, hit web pages. Sometimes there is free memory, sometimes it pops to the top and stays there -- but at no time does it appear to be having trouble. I opened a few shells and set up directory scans where we would see core dumps if our ecommerce stuff were to go nipples north, and nothing doing -- no sign of problems at all.
As long as it knows to throw cached memory stuff out in favor of stuff it actually needs to load and run or work with, I am guessing it'll be OK. Its not like its short on main memory. I'll watch it, and I'll play with it a bit. Since this particular server isn't online to the world (unless we lose a primary server) it's not quite the same thing as a full on server test, but my first impression is that whatever was wrong, this got around it one way or another. If it runs for a few days (and I will keep prodding it) I'll swap it with the primary server IP and we'll see how it does under load. We're pretty busy this time of year. I'll let you know.
You da man. :) Thanks again.
I've fallen off your lawn, and I can't get up.
Excel is probably from the verb 'to excel'. By Open Source standards, it's shameless and disgusting self-promotion.
Saying that OS is incapable of promoting good brand names is wrong. Apache, gimp, pine --- they are all names which are widely recognized, even by people who prefer Windows to Linux. And who didn't hear about emacs v. vi wars?
"Long run is a misleading guide to current affairs. In the long run we are all dead." (John Maynard Keynes)
I use OS X more for reasons of backwards compatability and hardware lock-in than anything else. That, and Windows makes my ass bleed. I fell out of love with Apple when I saw where they were going with OS X and when they started catering to the Yuppy/GAP crowd... but l my high school sweetheart getting implants and a cel phone isn't going to drive me into the arms of bubba, the 400lb prison stud who bathes annually (aka, Windows), or the dork with the emo glasses and the overbite who thinks being a dork is cool because the only media he takes in says it is (aka, Linux).
:-|
:P
.txt was supposed to be the document interchange standard. .pdf is boiled dog ass... especailly acrobat. :|
MS are a bunch of shits about product support on the Mac (this includes Office- which, while featureful, is fucking slow- even on current hardware with enough ram to kill a moose.)- specifically, windows media. No reason to speak of for Apple to play nice with Quicktime on the PC. Or iTunes for that matter- and do note that both apps use "brushed metal", and both apps used it before OS X had shipped a single copy.
Shit, the Quicktime Player for the Mac is pretty shitty in some respects- it's more useful as an interface to the API than it is as a media player.
I can't speak for Windows, but Adobe has (in their minds) every reason to be a complete pissass to Apple, at least passive aggressively- notice they dropped Premiere.... which elicited a buttload of OH NOEZ VIDEO EDITING ON TEH MAC IS DOOMED! from the windows crowd, and a buttload of relieved THANK GOD PREMIERE SUCKED ASS from anyone who's ever had to deal with it, especially since the advent of Final Cut Pro (which is cost competetive and wipes the floor with Premiere).
One could say Apple isn't doing a stellar job of keeping Big Software happy on the platform. One could also say that Apple is buying up software and putting out their own apps (iLife, the pro suite) because, realistically speaking, any Big Software equivalent sucks shit through a straw.
Probably because Adobe needs to move units to make money- so it's useful to them to withhold Really Useful Features until much later in the game- notice how long it took them to add 16-bit editing to Photoshop. Eventually they'll have no choice but to make their apps _useable_, as they will have exhausted all other viable means for extorting profit.
Adobe interface sucks ass- compare to Macromedia apps in any arena where the two compete (Imageready is CREAMED by Fireworks, GoLive is _ass_ compared to Dreamweaver, etc).... and dear gods, I thought
Makes me wish OSS would hurry up and prestidigitate a Photoshop clone. (by which I mean clone, as in, can't tell the difference outside of the splash screen. Same shortcuts, same tool handling, etc. More would be nice but I'm ranting enough as it is.)
So. Big Software Sucks. Fuck, it's 2004 and software developers have yet to produce a web browser that does everything totally frigging awesome. They're not even close. And a web browser is, in many respects, a hell of a lot simpler than a video editing system or an image manipulation system.
/proc/sys/vm/swappiness was new for 2.6 and doesn't exist in 2.4 (and I don't think it's been backported). Turning swap on and off is easy (swapon /dev/hda2 and swapoff /dev/hda2), adding swap is easy (dd if=/dev/zero of=some_file; mkswap some_file; swapon some_file).
Things like "overcommit_memory" will be on or off (echo 1 >/proc/sys/vm/overcommit_memory as an example, some distros will probably have a kernel tweaks GUI that allows this sort of stuff).
Oolite: Elite-like game. For Mac, Linux and Windows
Probably the thing I miss the most in Linux/Unix is the general lack of intelligent configuration. Not auto-configuration, but configuration programs that do just a little thinking of their own to come up with good suggestions.
I also frequently bemoan the lack of a good printer discovery service. It ought to be easy to ask what printers are accessible, even Windows can do that. But no, you have to type in the queue name or even IP address (good luck with that when the IP is dynamic). Grr...
P.S. Pet peeve: Configuration windows that lets you choose from one item only and don't notice that it might as well be skipped.
-Lars
Try this sometime:
Write a program which changes your standard UNIX password using PAM.
Then:
Compile it for Slowaris.
Then:
Compile it for PH-UX.
Then:
Compile it for Linsux.
Each of these has its own "prompts" it feeds back, and nothing in the man pages, or the "standard", says what that prompt is.
Error? Tough shit. You lose. And no, we're not going to indicate just how you lost. It's up to your program to guess.
Feh. PAM sucks.
For geeks like you and me, sure.
Actually, for the end-user even more so. My mother was very, very happy with Afterstep. It is a quantum leap easier for her than windos. And yes, she tried windos, she disliked it.
See, the point is that the end-user can not tailor the system to his or her needs, but they can have it tailored and very specifically so.
They don't need extra questions like, "Are you using KDE or Gnome?"
People have the same problem in windos, namely that they have no idea what the program is called, it's "the text editor" (and your tech support guy can guess whether they're using notepad, wordpad, word, or some 3rd party thing).
Beg pardon, but Mac OS X has a CLI much like Linux
You're right on that, of course. I forgot.
Assorted stuff I do sometimes: Lemuria.org
We can (probably rightly) assume that the GP is lying or has an otherwise unusual situation,
So why are you arguing against the - just as likely - assumption that he simply fucked up his system?
Nobody says Linux can not be made slow. I can certainly bring my system to a halt if I try hard (keyword: thrashing point). I can surely imagine people doing it unintentionally.
But that's not a problem with Linux, nor with Unix in general, and very certainly not of the kind that the GP claimed.
Assorted stuff I do sometimes: Lemuria.org
Anecdotal evidence doesn't mean a thing.
Pot, meet kettle.
The parent was giving even less data and was trying to claim a general problem.
Assorted stuff I do sometimes: Lemuria.org
Actually, for the end-user even more so. My mother was very, very happy with Afterstep. It is a quantum leap easier for her than windos. And yes, she tried windos, she disliked it.
See, the point is that the end-user can not tailor the system to his or her needs, but they can have it tailored and very specifically so.
I absolutely agree that in cases where a techie can be available to support it and customize it personally, it's better in most ways that anything the MS world has to offer. However, most people aren't in that position (at least, I would assume not: obviously most people I know well are in that position, as I'm there), and for them, having a relatively standard GUI layout would be a godsend to Linux on the desktop.
Now, I'm not saying that there should be a single GUI with no changes between machines: themes are great, and a theme someone likes can make them much happier with their system. All I'm worried about is locations and names of common buttons, windows, widgets, etc. That way, when the poor user calls tech support complaining that something doesn't work, the tech support person can walk them through steps without having to say "Well, the button is supposed to be labeled 'OK', and it should be in the bottom-right corner, but it might be in the bottom-left and called 'Aye, sir!'".... (Yeah, that's a bit extreme; I'm just trying to illustrate the point ;-) )
I'd be as happy as anyone to see Linux take huge chunks of Windows's desktop share. However, I do think that some real standardization is necessary in Linux to reach the average user who doesn't have technically inclined friends and relatives. Personally, I think that Mac OS X has the best of all worlds, but I'll admit I'm somewhat biased there.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
In any case, swap clearly has something to do with it. Luckily, these machines have more memory than they typically need, and I think an actual need for swap does not exist in the circumstances we have set up for normal operations.
One thing: We've not had any trouble with machines staying up; just with noticable slowdowns. One thing you might try is to open a large application (some open office component might do, they're really piggy/bloated) on one of these machines that has been up for a while and see how fast it comes up. Then reboot the machine and do it again with the system's memory uncommitted.
That's the kind of thing that made it obvious to me there was a problem. Window dragging was pretty awful too -- stuttering, late (and slow) redraws in areas the window had traversed during the drag -- not anymore, though. I used swapoff -a and that seems to have disrupted the problem situation; so far, there is no sign of repeated slowdown, and most (not quite all) memory is pretty well all comitted to something -- program, cache, buffers.
We've had this problem ever since RH9 came out. It's funny that swap control was there all the time; I've asked in numerous venues and looked around, but I never could find it. I guess it's not a commonly used facility.
I've fallen off your lawn, and I can't get up.
It... almost sounds like a large process is eating up a lot of memory, forcing other processes out to swap, and then dying, leaving those processes in a swapped state.. then other processes used the disk to generate the cache. That's what the symptoms sound like, unless you really are hitting some obscure kernel bug somehow. It sounds really odd. I do recommend trying the latest 2.4 kernels.
We've had this problem ever since RH9 came out
Aah, we upgraded straight from RedHat 7.1 (albeit a heavily modified and upgraded 7.1.. had XFree86 4.1, kernel 2.4.24) to Fedora Core 2.
I wish I had a nickel for every time I've had to struggle with a Unix program written from a Windows or Mac mindset.
Wow man. You used byzantine twice in three paragraphs. Come off it. Especially when you're trying to argue that the information on MSDN is written at too advanced a level. Welcome to my foe list.
> You are completely bewildered.
you're just upset because i pointed out that your proprietary software is irrelevant. that must be a hard thing to come to terms with.
>I am not talking to, or about, the "free
> software community" as you construe it in the
> parent. I am talking about the user community.
you obviously don't get it. free software users aren't just another market of passive consumers. even those of us who don't code tend to have much higher standards for what they expect from software than software consumers (with the notable exception of Mac users - they have very high standards too).
> Most of them won't give a rats left buttock if
> I open the source or not;
wrong. most of them do. even if they don't and can't code it themselves, they know that they benefit from source code being available for scrutiny and modification by others. they understand the evolutionary nature of free software, and they appreciate the security and quality and other benefits.
without source (and a Free Software license), most free software users won't be in the least bit interested in your proprietary ball-and-chain. they know the inherent traps of proprietary software.
> f the subsection of the user community that
> you represent doesn't want to take advantage
> of something free my company offers without
> source
there *IS* no advantage in proprietary, binary-only software.
> All I get out of your immensely silly position
> is broad sense of amusement that you would
> choose to keep using a stone knife because you
> have the assembly diagram for it even though I
> offer you a free table saw and make no move to
> deny you your stone knife, either.
that's a good one. hilarious, considering the relative quality of free software compared to proprietary crapware.
you can keep your proprietary garbage. thanks, but no thanks.
btw, it's more than just having the "assembly diagram" as you put it. it's also about what i can do with the software, how i can use it and re-use it, whether i can modify it to suit my particular needs, and (just as importantly) whether my data will be trapped in some proprietary piece of shit that i'll never be able to get it back out of, and which will stop working at some point in the future either because of licensing problems or because it only works with some ancient library which has been superceded for years.
for example, as well as being geeks, my partner and i run a bookshop. when we bought the shop a few months ago, it came with an ancient (circa 1996) windows PC which had a stock control and POS system for bookshops installed. aside from the fact that this software is ancient, buggy, and slow, and doesn't even produce what we would consider to be useful reports (the reports it does are more concerned with re-ordering stock than with telling us what sold and what didn't sell in the last week or month or whatever) we can't even upgrade the hardware because the damn thing checks for a hidden license somewhere on the system.
of course, we're writing our own to replace it - perl, ncurses, postgres.
when we finish it, we're going to have to throw away all the data that's in the existing system (which goes back several years - mostly details about books), because there is no way to export it, and it's in some bizarro cobol db format which isn't worth the effort to reverse engineer.
> You just keep on snuggling up to that source
> code, I'm so sure it'll make manipulating your
> images a whole lot easier and more fruitful.
well, yes, of course it does. manipulating images with embedded scripting languages like perl or python is far more productive than pointing and clicking with a mouse. it's a computer's job to do boring and repetitive stuff, not a human's.
> Excuse me, I really need to go off and chuckle
> for a while. Thanks for the absurdity.
Flamebait? What? It's supposed to be (+5, Funny). You know, classic Fortune cookie... Ah well, it's not funny if I try to explain it. Whoever modded this flamebait has no sense of humor.
Your Ad Here! $2.00 Per Day!
There is a package management system called encap that does that automagically. There is a program called "epkg" that implements it very well.
I do
Epkg also helps maintain /usr/local, and can maintain a /usr/local for binaries it can't run. I have sites with Solaris servers and mixed Solaris/Linux clients, and use the Solaris version of epkg to help maintain both trees.
I think it's the most unixy way to do package management.
Raise your children as if you were teaching them to raise your grandchildren, because you are.
I found GIMP can be a bit nasty when opening large files, so it might be GIMP rather than the OS. I've used GIMP on my 1GHz desktop, and my 2.5GHz laptop, and it's crawled to a halt on the laptop when loading large images...
also, I'd suggest that comparing your desktop with your server doesn't really give any decent statistics. You'd really want to run the trials on your server, then restart it and run the same trials. With nothing going on the background. You never know what might be up with your server... just a thought.
Actually dump won't work. Due to changes in the 2.4 and 2.6 kernels, dump won't get a consistent picture of the filesystem. Linus's comment seems to suggest dump doesn't get the right things from the buffer and page cache. Given that dump doesn't backup your data correct, it's worthless.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
Sorry, I was unclear, mixing writing styles foolishly. I meant desktop as in, Gnome. On the same server, or any other machine here, the Gimp will run well if the machine is newly booted.
The same effect occurs on my daily-use machine or any of the servers. They are very similar, though there are speed and total memory differences. They're all decent sized machines, though.
Since turning off swap the other day, a backup server has remained quite fast. On the weekend, I'm going to try that with a front line server, and see what happens.
I've fallen off your lawn, and I can't get up.
I've fallen off your lawn, and I can't get up.
So climb back into that kettle and cook some more. Clearly, you're not "done" yet.
Of course, this is slashdot, and we all know what that means...
I've fallen off your lawn, and I can't get up.
After reading all of these posts (well the highly modded ones anyway) it seems that there just needs to be 2 *types* of UNIX and then various distro's modelled around these 2 types of systems. One is a user-based system (single user - as in at my house, for me and maybe one or two other people) and then a server type that has a more traditional layout. UNIX is great right now for managing many users. We don't need things to be in /usr/New Program/bin and then add that path to our $PATH. We need a /bin/ /sbin /usr/bin and /usr/sbin /etc blah blah blah because it works great the way it is. For home users, the current UNIX system sucks. It is made for people who like to constantly fiddle and tweak shit ALL THE TIME. Yes this post would have to be 100 pages to get my full point across but what I am seeing is that a lot of people are saying to use MacOSX because its the perfect UNIX. It's not. It's a pain in the ass for a lot of different things (windows interoperability...shares hang, you still have error messages hidden behind the GUI), but its very easy for a home user (drag the .APP to the APPS folder and voila). There almost needs to be a traditional system with the traditional layout (so stuff can be mounted via NFS, all the users are in /home, /etc might reside on another box, etc), that is easy for a sysadmin to administer. But the one main issue that I have with *NIX is that there are too many proverbial cooks in the kitchen. Everyone is doing things their own way, not everyone has the time to (freely) update their software to work with GTK2 when they already have something running on GTK1.x (same for QT) etc etc etc. Installers do not behave the same way, blah blah blah... there is just too much going on and not enough quality control. This means that we geeks have to have several versions of shared libs installed for the plethora of apps we have installed. I personally hate having a whack of GTK apps and then I find ONE that needs QT and a bunch of other libraries installed - now I just increased my system by 2MB for the program I want and 50MB for everything it (alone) requires. This is basically an disorganized rant, but you see where I'm going. It would take a lot of effort to standardize graphics libs, networking libs, FS layouts, default FS's, etc because THERE ARE TOO MANY WAYS TO DO THINGS - but you know what? WE LIKE THAT, but now its basically shooting us in the foot because once we download everything we want on our desktop (and customize all the menu's in our GUI because the menu's don't build themselves upon installation), we have a messy system that is not easy to rebuild without all that tinkering. Basically distros that are labelled as servers come with more server apps, security suites etc. The desktop distros come with more user utilities, games, graphics, pim, etc, but underneath they are both the same and this doesn't work well. We need a major overhaul.
You create your own reality - Leave mine to me.
Once I figure it out I'll try ...
I suspect it's the older KDE I have with KDEINIT growing over time.
I'm usually to busy tring to work to have time to solve it on monday Mornings when it usually strikes.
Type unto others as you would have them type unto you.
We've been down these roads, though. I've sat through many cups of coffee -- I don't sleep much anyway, missing a couple nights doesn't seem to bother me much -- watching the server status displays, and at no time do these systems eat a lot of memory. They build losts of buffers and cache over about two days. The levels stay essentially stable (small changes occur, but we're talking just a few percent there.) Then the system begins to swap, and at that time, the slowdown begins.
There is a known kernal bug in 2.4.20-6 that has symptoms along these lines, but Redhat never fixed it. Someone here showed me how to turn off swapping, whcih I did, and that seems to have resolved the problem. I swapped the backup server with the online server last night at 3AM which is a pretty dead time, and I've been watching it as the load came up today -- it's still fast as it should be, and there are zero signs of memory issues. About 70% of memory is cache and buffers, the rest is program, and I've been all over the site -- revision reporting, web pages, ordering, comment submission, downloading, basically every service the server offers to the world, I've used it since I turned off swapping and nothing is acting unusual except that it is as fast as it is when the machine is newly booted -- which is unusual. :)
I don't much want to go to Fedora at this time -- the claimed "experimental" nature of it leaves me more than a little unsettled -- and I'm really kind of annoyed at Redhat for not fixing something as critical and basic as this (and for abandoning the RH9 product in general, don't even get me started on that) which makes me unwilling to give them any more money. So if we can stay with this release, I'm going to, at least for a while.
Thanks for your comments; I very much appreciate yours, and those of the other helpful people who showed up in and amongst the weenies who claimed such a problem was impossible. While they were yapping like annoying little terriers, the expert Linux folks reached out and provided the solution to the problem.
I've fallen off your lawn, and I can't get up.
Hmmmm... if the newest of the 2.4.x kernels doesn't fix this problem for you, then I suggest sending mail to the Linux Kernel Mailing List. Even if they can't fix it directly (and there are still some people working on the 2.0.x from time to time, so improvements to 2.4.x shouldn't be too unlikely), they may still be able to offer more concrete suggestions and ideas for what could be going wrong.
Thanks for your comments; I very much appreciate yours, and those of the other helpful people who showed up in and amongst the weenies who claimed such a problem was impossible.
Yes well.. those of us with enough experience in the field know that nothing is impossible. ;)
I read about it and then figured a way around it the first day I got the Win2K RTM disk. Just write a copy of your file to the \dllcache first and then write a copy to \system32.
Hm... setting up my HP LaserJet with Linux was easy (Start print-config, give connection type JetDirect, enter IP address, choose "Postscript printing". Ready).
Setting it up with Solaris was more tedious, but doable. (Go to HP website, search for "HP LaserJet Solaris", download software, read README, run config.)
What really took me about three days was getting the HP running with Windows 2000. Windows 2000 natively doesn't know any JetDirect, and if you go to HP's website, you find a java based tool, which tries to load software from a webpage which no longer seems to exist. In the end I went and bought a parallel cable to have the printer running, which slows printing quite down. After some telnetting around into the printer itself I fiddled around with some configs, and finally it ran also over Ethernet.
So for professional printing equipment give me Linux or Solaris any day. I might have done more easily with Windows, but, you know... I am new to Windows Admin stuff, and it is not really intuitive for me.
I'll let those-who-know answer the other points (if there are answers to them), as I don't have enough experience in those areas to comment.
This sig space intentionally left blank.