I use cash all the time. Besides the simplicity, it serves as a nice "control" for my spending. If I notice myself goign to the ATM too often, I am probably spending more money than I should. The credit card serves as a backup for the cash.
The government really does watch transactions for "suspicious" activity. For example, I read about a couple in Texas who got a visit from the Dept. of Homeland Security because they paid off their credit card too quickly. They sent in a check for like $6,000. Credit card companies are obligated to report such unusual activity to the government. Now what if every transaction was monitored? In a state of even higher elevated government paranoia, you can imagine a lot more innocent people getting visits from the "Men in Black," so to speak.
Talk about opportunities for loss of privacy. In a truely cashless society, there would be no way to have private transactions. Everything would be accounted for. Maybe it is one of those things where if you aren't doing anything wrong, you have nothing to worry about, but still. I'd like to keep the option of paying my dealer^H^H^H^H^Hbookie^H^H^H^H^Hfriend without some kind of electronic trail.
-matthew
Re:Transparent Windows: learn from Apple's Mistake
on
How Vista Disappoints
·
· Score: 1
That is two revisions, and only one added new features. OS X has changed a lot since it was first released. I'm not going to go into exactly what changed here, but suffice it to say that they were significant. Significant enough that a lot of new apps are only compatable with 10.3 and 10.4. Also each major release has had several "service packs" (10.4.6 currently). So if you want to count service packs as releases, then Microsoft really does look slow.
The bottom line is that most people will just use whatever is shipped with the OS. It doesn't really matter how outdated or bad it is. Well... within reason.
What if you terminate the employee for not getting their work done? Does it really matter whether they are not getting it done because they are browsing the web or because they are reading a novel or talking to the guy in the next cube for 5 hours a day? It certainly sounds silly to say you fired someone just for browsing the web, but when you can show it has tangible effects on their output.. well... that is quite a different story.
-matthew
Re:The one place I can really see this used...
on
WebOS Market Review
·
· Score: 1
Yeah, its called Microsoft Terminal Services (or Citrix if you need more features). Sun also tried pusing thin desktops years ago. Or you can try http://ltsp.org/ if you are into Linux. Heck, even just setting up roaming desktops and storing all user home directories (and documents) on the server should solve most of the thick client management headaches.
There are any number of better ways to do this than using a web browser.
With the move towards virtualization, etc -- would it really be so insane to consider in-browser virtualization code that lets you run code natively built for other another os? It's no longer really just a "browser" anyway.
Virtualization involves installing a whole OS, not just emulating a particular API. And yeah, it would be pretty insane (and pointless).
-matthew
Re:Covered in a previous Slashdot story...
on
WebOS Market Review
·
· Score: 1
Hopefully you'd be smart enough to use the talent for something a little more useful though.;-)
-matthew
Re:Reinventing the wheel again and again and again
on
WebOS Market Review
·
· Score: 1
Wrong. The reason the thin client hardware failed is that thick clients dropped below the $500 price point that that thin clients were aiming for.
But a thin client can be made out of the same hardware. The problem
Web applications, however, have shown that the managability advantages of the thin client architecture were something the market wanted.
Except, of course, that you don't get the managability advantages of a thin client. You get the managability advantages of a client/server application which is nothing new. The full client is still as thick as ever and the people who have to manage them still have the same headaches. Now, if people were booting an OS dedicated to just a browser, that might be differnt. But that just isn't happening.
Nobody needed to show that the market wanted server based applications. Just look at how hospitals still run terminal based health management applications.
Most CGI languages (Perl, PHP, etc.) are able to do anything a language can do and use the browser as an interface.
Anything in a "turing complete" sense, sure. But there are, in fact, many things that they can't do in practice. They can't access local hardware. They can't draw system widgets. They can't (ideally) do anything outside of the browser "sandbox."
The main drawback is that there is a lag time, particularly if you are on a slow connection.
No, the main drawback is the document model and the click-refresh-click cycle.
Javascript is faster, since it runs in the browser, but it is a limited language.
It isn't just Javascript. It is also HTML. If you had a decent UI toolkit, one wouldn't have to rely on Javascript so much.
So for now its Word and Photoshop on my computer, Safari or Firefox for web surfing and OS X Mail or webbased interfaces for e-mails. For the time being I don't see any other way around it.
Question is, why do you want to get "around" it? Is it really an obstacle?
-matthew
Re:Reinventing the wheel again and again and again
on
WebOS Market Review
·
· Score: 2, Insightful
The only thing that has held network applications back is bandwidth and price. Now thats not a problem anymore.
And the fact that (in this case) Javascript/DHTML/HTTP is almost completely unsuited for the task. I say "almost" because apparently some people have managed to cobble something together. At least Terminal Server/Citrix performs well. At least Sun's thin clients could actually act like they had a full local OS. People DO care what is under the hood if it performs like a tar covered pig in a room full of... more tar covered pigs. I can see it now: "Let me just ignore this local desktop with 3D accelerated menus, cool apps and games, lots of Vista/XP/OSX eye candy, and a decent looking widget set for this WebOS thing where I can get a glimpse of how graphical itnerfaces performed in the 80's. It's so retro! Yay!" Its a fucking joke is what it is.
-matthew
Re:Reinventing the wheel again and again and again
on
WebOS Market Review
·
· Score: 1
To be fair to previous thin client ideas, they weren't trying to sell to home users. They were trying to sell to businesses and schools. Businesses want a lot more control over desktops and thin clients are a good way to go about it. Sure, they mostly failed, but not necessarily because thin clients are a bad idea. I think eventually (tho not soon) admins will just get sick and tired of tryign to manage fat clients and make a push back to thin clients. Most corporate users are connected to the network 24/7 anyway. And if the network goes down, they often can't get any work done as it is (server based roaming desktops). The reason Sun failed with the thin client was because, well, it was Sun (and Java).
I find the idea of a whole suite of programs (i won't consider the 'OS' bit since it really makes no sense) that relies on web technology to be somewhat interesting.
Interesting in the same way that 3rd degree burns are interesting to a doctor.
Re:Transparent Windows: learn from Apple's Mistake
on
How Vista Disappoints
·
· Score: 1
Okay, but what about linux distros. YES, the KERNEL is labeled this way, but why not have everybody call their linux_kernel/app_land distro as 2.1.6.185.6.2 for redhat (185*) 6.2 (their release) based on the linux kernel 2.1.6 (yes, wierd numbers out of my butt, so what) and then we can just look at the numbers and go, oh, theres your problem, your trying to do that with 2.1.6.185.6.2 instead of using 2.1.6.21**.5.5
The problem with LInux is there is no clear distinction between the OS and applications. Each package has its own version and then the distribution maker puts an uber version on the whole thing. So what you get are applications that are built for specific distribution "uber" versions. That way someone can say "oh, there's your problem. You are trying to install a package built for Debian 3.1 on Debian 3.0.
cmon, only os/s get fancy real-world names, because they change (apparently/seemingly/according to marketing) drastically between releases. This sounds like a newb-ish rant, so I expect you'll get flamed everytime you rant this particular "advice". Nobody will change things, so you should give it up. Now, you can refer to win5.1 all you want, and we'll (most of us) know exactly what you're saying, so you can continue, as we all know how to do the reference in our own heads.
The versioning thing was actually a minor part of what I was talking about. My main point was the long release cycles and how it affects users "stuck" with a particular version for 5 years or more. Compare to OS X which has a nice steady release cycle while progressively adding features, making upgrades relatively painless. OS X went through 4 major releases in the time between XP and Vista.
Back to your point, the registry is the better tool for these users (those who are not admin, e.g. home users) needs, and I wholeheartedly agree with your point. How many users could be expected to find every.rc,.ini,.cfg or whatever you want to call it on their system if The Registry was not around. But the flipside is, how many users know about The Registry? Yeah, they've heard about it, and how it can cause problems. But can they navigate it? And Windows does have plenty of CL tools for doing things with the system. The register/unregister dll program runs either as an api or CL.
The Registry is definitly not there for hte users. Users are warned over and over again to avoid editting the registry. AFAICT, it is there for the convenience of developers. In Linux, most GUI programs do not require users to edit any config files either. So, as far as the user is concerned, that much is the same. What is nice about the unix model is that the user can ONLY modify his/her own home directory and the config files therein. No system stuff (registry) is every touched.
Insofar as Mac goes I definitely agree that the install process is much easier, as is working with the.sit (right, or sft?) format. But users are becoming more familiar with the whole compressed format on Windows.
Actually, SIT is the old way of doing it on Macs. Almost all programs for OS X are distributed in disk images (.dmg). You just mount (double click) the disk image and copy the application to/Applications or doubleclick the.pkg file. What is nice about Mac appliations is that many of them will run from anywhere. They are self contained. Just one "executable" containing all the components that program needs to run. It can run from teh user's desktop or/Applications. Usually the programs that need to run an "installer" are not pure Cocoa applications. Like say you install a "unix" applications like MySQL or something that needs to put files all over the place. But programs like MS Office can just be copied from one computer from another. As a matter of fact, that is how i got it from my wife's Mac. She just burned her/Applications/MS Office X folder and I copied it to my/Applications folder (my other computer is a Mac).
Yes, it's all very simple until you have to do something complicated. For example, having 9 bits of security is very simple. Now let's say you want to give read access to a file to 1000 different people. The only way to do that is to use the "group" bits and put those 1000 people in a single group. This sounds like a great idea, except the group list is stored in a simple text file, which will probably be parsed by a tool that has a 512 character line buffer. And even if your parser isn't arbitrarily limited, the model falls apart if you decide that you want a different set of people to write access. Of course, if you want only certain people to be able to delete the file, you are totally out of luck because the Unix security model doesn't include a "delete" bit. The "simple" way to do this on Unix is to create a program that runs suid which users would use to delete the file.
Be that as it may, the system works 99% of the time and it isn't cluttered with unnecessary complexity just to cover the 1% of corner cases. I'd rather have a system that does, simply, what I want 99% of the time, than have to deal with an overly complex system that makes me jump through hoops 100% of the time.
How about that registry, huh? I guess it's a much better idea to have text files randomly scattered about/etc,/var, home directories, and other places, each in its own format that you have to write your own parser for.
Why are you writing parsers for config files?
t's a good thing that Apache is open source, because its config files can't be parsed with a regex or a standard XML parser -- the only easy way to do it is to copy and paste the code from Apache. Let's hope that two people aren't trying to change the config at the same time, too, because there's no file locking to prevent somebody else from simultaneously writing to the file and completely corrupting it.
If you have two people simutaneously editing an Apache config file, you've got some systemic problems that need to be dealt with before you start complaining about non-locking filesystems. Personally, I've found the lack of locking to be a good thing. It has allowed me to easily do things such as full backups and in-place upgrades/updates, that woudl otherwise require complex (and often expensive) tools in Windows.
Simplicity is a great thing, but the problem is that Unix doesn't give you a choice. If you want to use a text processing tool to process Windows logs, it's trivial to just dump the log to a text file and process it.
But that is a manual process. Having the logs in text from the start makes things simpler to automate.
But if you want to process logs on a Unix box without writing a text parser first, you can't do it. Even if you do write a parser for a log file, you probably have to write another parser for the next log file.
What is it with you and "writing text parsers." A simple grep or cut or a short awk line is usually quite sufficient... and you never have to leave the commandline. I can't tell you how many times I have done rather sophisticated log/mailbox manipulations all using simple unix tools. Doing similar things on Windows usually requires some third party software and then you're lucky if the authors had exactly your problem in mind.
-matthew
Re:Transparent Windows: learn from Apple's Mistake
on
How Vista Disappoints
·
· Score: 1
Well, I can't say I've ever paid for any version of OS X (or WIndows), but I see your point. My poitn is that most casual users dont' know they can change things like that. And it would only be a subset of users who happened to buy a Mac when the UI was "bad" that would have to pay to upgrade. Because of the relatively fast paced release cycle of OS X, newer machines would ship with a newer OS. Windows users, on the other hand, are going to be stuck with Vista and its quirks for 5, 6, or 7 years. And then they will be upset when a service pack screws things up without warning because Microsoft has no concept of sane versioning and reasonable release cycles. If it is WIndows NT 5.3, then call it Windows NT 5.3. Don't give us this "2000 SP4" or "XP SP2" or "2003 SP1" or "Vista" crap. Just release version 5.1.3, 5.1.4, 5.2.0, etc like every other friekin software company.
From a user's perspective, perhaps not. Users tend to equate simpliciy and ease of use. From an administrative and programming (depending on what you are doing) POV, Linux/UNIX is simple. On the commandline you get a group of simple tools that can be chained and scripted together. No complex protocols or library stacks to link programs together, just a simple pipe that passes raw text/binary. You usually edit text files to conifgure things. No central registry system. Logs are raw text files that are easy to process and dont' require a special "Event Viewer."
Quite often things are made very complex in order to make them easy to use. Take an automatic transmission vs. a manual transmission for example. An automatic transmission is very easy to use, but any mechanic will tell you that a manual transmission is much simpler than the auto.
-matthew
Re:Transparent Windows: learn from Apple's Mistake
on
How Vista Disappoints
·
· Score: 2, Insightful
You'd think MS would learn from Apple's mistake... instead they took it to the next level of ridiculousness. When OS X first came out it was littered with transparent menus, menu bars, dialogs, etc. A lot of the elements have either been removed, or brought up to about 98% opacity. You might not even notice the transparency unless you really look closely.
And what makes it worse for MS is that they have such a long release cycle. So people are going to be "stuck" with a bad GUI for many years. Of course, you can probalby shut it off, but peopel are going to be impacted by the first (default) impression and some may not even think to try to fix it. 5 years from now, people are going to be buying new Dells with the same horrible defaults as Vista. Apple, on the other hand, has released several major versions of OS X in the time between Windows XP and Vista. And each time they tweaked things just a little bit... and almost always for the better.
-matthew
Re:Mr. Thurrott forgives Microsoft
on
How Vista Disappoints
·
· Score: 2, Insightful
IMHO it's isn't, NT had a unix-like security model (not exactly the same, but...)from the start. XP may created user accounts with administrator privileges by default, but the problem there is just a bad default, they could have changed it very easily in the vista code base or in a XP SP.
The reason they use such a bad default is because a lot of programs require admin rights to run and your average user doesn't want to bother (or doesn't know how to) use the "runas" feature. In this regard, the security model is bad. It should be more like OS X where the system knows when you need admin to do something and it automatically prompts for a username/password with admin rights. This is a superior security model for a consumer desktop, IMO. It has one great thing going for it: It is dead simple. Microsoft has gone out of their way (as usual) to make things very complex. One wonders if they've ever heard the old engineering mantra: Keep It Simple, Stupid (KISS).
On the other hand, an owner like Oracle could kill a loyal following. Especially if they lost the focus that Novell has in making a solid enterprise desktop (as well as all the other little projects Novell has going). Why would Oracle care about any of that stuff? I know I would stop using a distro if Oracle bought it.
Slashdot Mirror
I use cash all the time. Besides the simplicity, it serves as a nice "control" for my spending. If I notice myself goign to the ATM too often, I am probably spending more money than I should. The credit card serves as a backup for the cash.
-matthew
The government really does watch transactions for "suspicious" activity. For example, I read about a couple in Texas who got a visit from the Dept. of Homeland Security because they paid off their credit card too quickly. They sent in a check for like $6,000. Credit card companies are obligated to report such unusual activity to the government. Now what if every transaction was monitored? In a state of even higher elevated government paranoia, you can imagine a lot more innocent people getting visits from the "Men in Black," so to speak.
-matthew
Talk about opportunities for loss of privacy. In a truely cashless society, there would be no way to have private transactions. Everything would be accounted for. Maybe it is one of those things where if you aren't doing anything wrong, you have nothing to worry about, but still. I'd like to keep the option of paying my dealer^H^H^H^H^Hbookie^H^H^H^H^Hfriend without some kind of electronic trail.
-matthew
That is two revisions, and only one added new features. OS X has changed a lot since it was first released. I'm not going to go into exactly what changed here, but suffice it to say that they were significant. Significant enough that a lot of new apps are only compatable with 10.3 and 10.4. Also each major release has had several "service packs" (10.4.6 currently). So if you want to count service packs as releases, then Microsoft really does look slow.
-matthew
Could be Beta 2 Preview Release Candidate 1 Service Pack 2.
The bottom line is that most people will just use whatever is shipped with the OS. It doesn't really matter how outdated or bad it is. Well... within reason.
My home country is the fatherland, you insensitive clod!
What if you terminate the employee for not getting their work done? Does it really matter whether they are not getting it done because they are browsing the web or because they are reading a novel or talking to the guy in the next cube for 5 hours a day? It certainly sounds silly to say you fired someone just for browsing the web, but when you can show it has tangible effects on their output.. well... that is quite a different story.
-matthew
Yeah, its called Microsoft Terminal Services (or Citrix if you need more features). Sun also tried pusing thin desktops years ago. Or you can try http://ltsp.org/ if you are into Linux. Heck, even just setting up roaming desktops and storing all user home directories (and documents) on the server should solve most of the thick client management headaches.
There are any number of better ways to do this than using a web browser.
-matthew
With the move towards virtualization, etc -- would it really be so insane to consider in-browser virtualization code that lets you run code natively built for other another os? It's no longer really just a "browser" anyway.
Virtualization involves installing a whole OS, not just emulating a particular API. And yeah, it would be pretty insane (and pointless).
-matthew
Hopefully you'd be smart enough to use the talent for something a little more useful though. ;-)
-matthew
Wrong. The reason the thin client hardware failed is that thick clients dropped below the $500 price point that that thin clients were aiming for.
But a thin client can be made out of the same hardware. The problem
Web applications, however, have shown that the managability advantages of the thin client architecture were something the market wanted.
Except, of course, that you don't get the managability advantages of a thin client. You get the managability advantages of a client/server application which is nothing new. The full client is still as thick as ever and the people who have to manage them still have the same headaches. Now, if people were booting an OS dedicated to just a browser, that might be differnt. But that just isn't happening.
Nobody needed to show that the market wanted server based applications. Just look at how hospitals still run terminal based health management applications.
-matthew
Most CGI languages (Perl, PHP, etc.) are able to do anything a language can do and use the browser as an interface.
Anything in a "turing complete" sense, sure. But there are, in fact, many things that they can't do in practice. They can't access local hardware. They can't draw system widgets. They can't (ideally) do anything outside of the browser "sandbox."
The main drawback is that there is a lag time, particularly if you are on a slow connection.
No, the main drawback is the document model and the click-refresh-click cycle.
Javascript is faster, since it runs in the browser, but it is a limited language.
It isn't just Javascript. It is also HTML. If you had a decent UI toolkit, one wouldn't have to rely on Javascript so much.
So for now its Word and Photoshop on my computer, Safari or Firefox for web surfing and OS X Mail or webbased interfaces for e-mails. For the time being I don't see any other way around it.
Question is, why do you want to get "around" it? Is it really an obstacle?
-matthew
The only thing that has held network applications back is bandwidth and price. Now thats not a problem anymore.
And the fact that (in this case) Javascript/DHTML/HTTP is almost completely unsuited for the task. I say "almost" because apparently some people have managed to cobble something together. At least Terminal Server/Citrix performs well. At least Sun's thin clients could actually act like they had a full local OS. People DO care what is under the hood if it performs like a tar covered pig in a room full of... more tar covered pigs. I can see it now: "Let me just ignore this local desktop with 3D accelerated menus, cool apps and games, lots of Vista/XP/OSX eye candy, and a decent looking widget set for this WebOS thing where I can get a glimpse of how graphical itnerfaces performed in the 80's. It's so retro! Yay!" Its a fucking joke is what it is.
-matthew
To be fair to previous thin client ideas, they weren't trying to sell to home users. They were trying to sell to businesses and schools. Businesses want a lot more control over desktops and thin clients are a good way to go about it. Sure, they mostly failed, but not necessarily because thin clients are a bad idea. I think eventually (tho not soon) admins will just get sick and tired of tryign to manage fat clients and make a push back to thin clients. Most corporate users are connected to the network 24/7 anyway. And if the network goes down, they often can't get any work done as it is (server based roaming desktops). The reason Sun failed with the thin client was because, well, it was Sun (and Java).
-matthew
I find the idea of a whole suite of programs (i won't consider the 'OS' bit since it really makes no sense) that relies on web technology to be somewhat interesting.
Interesting in the same way that 3rd degree burns are interesting to a doctor.
-matthew
But isn't wardriving illegal?
Okay, but what about linux distros. YES, the KERNEL is labeled this way, but why not have everybody call their linux_kernel/app_land distro as 2.1.6.185.6.2 for redhat (185*) 6.2 (their release) based on the linux kernel 2.1.6 (yes, wierd numbers out of my butt, so what) and then we can just look at the numbers and go, oh, theres your problem, your trying to do that with 2.1.6.185.6.2 instead of using 2.1.6.21**.5.5
The problem with LInux is there is no clear distinction between the OS and applications. Each package has its own version and then the distribution maker puts an uber version on the whole thing. So what you get are applications that are built for specific distribution "uber" versions. That way someone can say "oh, there's your problem. You are trying to install a package built for Debian 3.1 on Debian 3.0.
cmon, only os/s get fancy real-world names, because they change (apparently/seemingly/according to marketing) drastically between releases. This sounds like a newb-ish rant, so I expect you'll get flamed everytime you rant this particular "advice". Nobody will change things, so you should give it up. Now, you can refer to win5.1 all you want, and we'll (most of us) know exactly what you're saying, so you can continue, as we all know how to do the reference in our own heads.
The versioning thing was actually a minor part of what I was talking about. My main point was the long release cycles and how it affects users "stuck" with a particular version for 5 years or more. Compare to OS X which has a nice steady release cycle while progressively adding features, making upgrades relatively painless. OS X went through 4 major releases in the time between XP and Vista.
-matthew
Back to your point, the registry is the better tool for these users (those who are not admin, e.g. home users) needs, and I wholeheartedly agree with your point. How many users could be expected to find every .rc, .ini, .cfg or whatever you want to call it on their system if The Registry was not around. But the flipside is, how many users know about The Registry? Yeah, they've heard about it, and how it can cause problems. But can they navigate it? And Windows does have plenty of CL tools for doing things with the system. The register/unregister dll program runs either as an api or CL.
.sit (right, or sft?) format. But users are becoming more familiar with the whole compressed format on Windows.
/Applications or doubleclick the .pkg file. What is nice about Mac appliations is that many of them will run from anywhere. They are self contained. Just one "executable" containing all the components that program needs to run. It can run from teh user's desktop or /Applications. Usually the programs that need to run an "installer" are not pure Cocoa applications. Like say you install a "unix" applications like MySQL or something that needs to put files all over the place. But programs like MS Office can just be copied from one computer from another. As a matter of fact, that is how i got it from my wife's Mac. She just burned her /Applications/MS Office X folder and I copied it to my /Applications folder (my other computer is a Mac).
The Registry is definitly not there for hte users. Users are warned over and over again to avoid editting the registry. AFAICT, it is there for the convenience of developers. In Linux, most GUI programs do not require users to edit any config files either. So, as far as the user is concerned, that much is the same. What is nice about the unix model is that the user can ONLY modify his/her own home directory and the config files therein. No system stuff (registry) is every touched.
Insofar as Mac goes I definitely agree that the install process is much easier, as is working with the
Actually, SIT is the old way of doing it on Macs. Almost all programs for OS X are distributed in disk images (.dmg). You just mount (double click) the disk image and copy the application to
-matthew
Yes, it's all very simple until you have to do something complicated. For example, having 9 bits of security is very simple. Now let's say you want to give read access to a file to 1000 different people. The only way to do that is to use the "group" bits and put those 1000 people in a single group. This sounds like a great idea, except the group list is stored in a simple text file, which will probably be parsed by a tool that has a 512 character line buffer. And even if your parser isn't arbitrarily limited, the model falls apart if you decide that you want a different set of people to write access. Of course, if you want only certain people to be able to delete the file, you are totally out of luck because the Unix security model doesn't include a "delete" bit. The "simple" way to do this on Unix is to create a program that runs suid which users would use to delete the file.
/etc, /var, home directories, and other places, each in its own format that you have to write your own parser for.
Be that as it may, the system works 99% of the time and it isn't cluttered with unnecessary complexity just to cover the 1% of corner cases. I'd rather have a system that does, simply, what I want 99% of the time, than have to deal with an overly complex system that makes me jump through hoops 100% of the time.
How about that registry, huh? I guess it's a much better idea to have text files randomly scattered about
Why are you writing parsers for config files?
t's a good thing that Apache is open source, because its config files can't be parsed with a regex or a standard XML parser -- the only easy way to do it is to copy and paste the code from Apache. Let's hope that two people aren't trying to change the config at the same time, too, because there's no file locking to prevent somebody else from simultaneously writing to the file and completely corrupting it.
If you have two people simutaneously editing an Apache config file, you've got some systemic problems that need to be dealt with before you start complaining about non-locking filesystems. Personally, I've found the lack of locking to be a good thing. It has allowed me to easily do things such as full backups and in-place upgrades/updates, that woudl otherwise require complex (and often expensive) tools in Windows.
Simplicity is a great thing, but the problem is that Unix doesn't give you a choice. If you want to use a text processing tool to process Windows logs, it's trivial to just dump the log to a text file and process it.
But that is a manual process. Having the logs in text from the start makes things simpler to automate.
But if you want to process logs on a Unix box without writing a text parser first, you can't do it. Even if you do write a parser for a log file, you probably have to write another parser for the next log file.
What is it with you and "writing text parsers." A simple grep or cut or a short awk line is usually quite sufficient... and you never have to leave the commandline. I can't tell you how many times I have done rather sophisticated log/mailbox manipulations all using simple unix tools. Doing similar things on Windows usually requires some third party software and then you're lucky if the authors had exactly your problem in mind.
-matthew
Well, I can't say I've ever paid for any version of OS X (or WIndows), but I see your point. My poitn is that most casual users dont' know they can change things like that. And it would only be a subset of users who happened to buy a Mac when the UI was "bad" that would have to pay to upgrade. Because of the relatively fast paced release cycle of OS X, newer machines would ship with a newer OS. Windows users, on the other hand, are going to be stuck with Vista and its quirks for 5, 6, or 7 years. And then they will be upset when a service pack screws things up without warning because Microsoft has no concept of sane versioning and reasonable release cycles. If it is WIndows NT 5.3, then call it Windows NT 5.3. Don't give us this "2000 SP4" or "XP SP2" or "2003 SP1" or "Vista" crap. Just release version 5.1.3, 5.1.4, 5.2.0, etc like every other friekin software company.
-matthew
From a user's perspective, perhaps not. Users tend to equate simpliciy and ease of use. From an administrative and programming (depending on what you are doing) POV, Linux/UNIX is simple. On the commandline you get a group of simple tools that can be chained and scripted together. No complex protocols or library stacks to link programs together, just a simple pipe that passes raw text/binary. You usually edit text files to conifgure things. No central registry system. Logs are raw text files that are easy to process and dont' require a special "Event Viewer."
Quite often things are made very complex in order to make them easy to use. Take an automatic transmission vs. a manual transmission for example. An automatic transmission is very easy to use, but any mechanic will tell you that a manual transmission is much simpler than the auto.
-matthew
You'd think MS would learn from Apple's mistake... instead they took it to the next level of ridiculousness. When OS X first came out it was littered with transparent menus, menu bars, dialogs, etc. A lot of the elements have either been removed, or brought up to about 98% opacity. You might not even notice the transparency unless you really look closely.
And what makes it worse for MS is that they have such a long release cycle. So people are going to be "stuck" with a bad GUI for many years. Of course, you can probalby shut it off, but peopel are going to be impacted by the first (default) impression and some may not even think to try to fix it. 5 years from now, people are going to be buying new Dells with the same horrible defaults as Vista. Apple, on the other hand, has released several major versions of OS X in the time between Windows XP and Vista. And each time they tweaked things just a little bit... and almost always for the better.
-matthew
IMHO it's isn't, NT had a unix-like security model (not exactly the same, but...)from the start. XP may created user accounts with administrator privileges by default, but the problem there is just a bad default, they could have changed it very easily in the vista code base or in a XP SP.
The reason they use such a bad default is because a lot of programs require admin rights to run and your average user doesn't want to bother (or doesn't know how to) use the "runas" feature. In this regard, the security model is bad. It should be more like OS X where the system knows when you need admin to do something and it automatically prompts for a username/password with admin rights. This is a superior security model for a consumer desktop, IMO. It has one great thing going for it: It is dead simple. Microsoft has gone out of their way (as usual) to make things very complex. One wonders if they've ever heard the old engineering mantra: Keep It Simple, Stupid (KISS).
-matthew
On the other hand, an owner like Oracle could kill a loyal following. Especially if they lost the focus that Novell has in making a solid enterprise desktop (as well as all the other little projects Novell has going). Why would Oracle care about any of that stuff? I know I would stop using a distro if Oracle bought it.
-matthew