Except for the part where practically every app you install overwrites some DLL that came with Windows or another app - whether it's a newer version or not. With Linux, you have versioned libraries, so you can have different versions of the same library around to accomodate older apps. Also, Unix/Linux definitely assumes more knowledge on the part of the user, but you get an infinitely more flexible system. Macintosh is pretty much designed for dummies. (I'm sorry, but it's true...) Windows is supposed to be end-user-oriented, but with all the shortcomings it has, it's certainly not as user-friendly as it's billed.
Probably because, as someone else noted, to Mac users the application is completely engendered in the GUI. If it doesn't have a pretty GUI, it's probably not worth using, in their estimation. Whereas Linux users (I for one) don't necessarily care as much about a pretty GUI - the app's value is in if it fulfills a need. If it has a GUI, it should be functional, and looking decent is a nice side benefit. To us, a command-line is very useful because that's the kind of system we want - it allows us to use apps and utilities as components to accomplish something. (Whatever that may be.) Whereas with most Mac users, it has to be simple. A command-line is ugly, and it has no pictures. It's not simple, so it's simply not worth doing.
The MacOS system and attitude feels to me like a marketing concept, a billboard...a tool to provide Apple Computer with revenue.
Well, isn't that basically what it is? The OS is made simply to complement their hardware. Apple is, after all, a hardware company. They're definitely not making THAT much money from the OS...
I've heard this point made before. "People just want to be able to use a computer, without having to read 10 thousand page manuals or go through 6 months of training - it's just a tool to them!" Yes, it's a tool, but the problem is the traditional "tool" perspective doesn't work with a computer.
If you have a knife, or a screwdriver, hammer, etc., it has a SIMPLE purpose. It's designed to do one specific thing and do it well. (You can probably substitute one tool for another in certain circumstances, but that's not necessarily a good idea.) I'm sure the medical prototype device you were referring to, also, had a pretty specific purpose. (Correct me if I'm wrong.)
A general-purpose computer can't be thought of in the same way, however, due to its nature. It's a multifaceted beast - it can do a myriad of things, but to get it to do any of them well, you have to have some mastery of the machine. You need to know how to tell it, specifically, what it is you want it to do, and how you want it done. Yes, with little or no training and a pretty GUI to guide, a user can probably do some tasks, using the computer, and do them decently. But they'll never be able to do them well, without being able to actively engage the computer and understand how it works well enough to communicate to it what you want.
Just MHO, but that's simply my take on why you HAVE to be willing to learn to use a computer, and why the "just a tool" mentality is all wrong.
There is no good reason why $_, @_, $@, etc. should be legal variable names in any language. They're pure nonsense. Why couldn't they be given more descriptive names?
Umm. Try 'perldoc perlvar' sometime, you might learn something. (Like that there ARE long aliases for those variables if you want them, it's just a matter of reading.)
... anyone who's tried to show a bash shell to somebody who's never seen an UNIX-style command line but is otherwise highly computer-literate.
This is interesting. How computer-literate is the average Mac or Windows user, really? Not particularly. And why, might I ask? Because they're used to using an OS that tries to eliminate the need for computer literacy (sometimes not doing a particularly good job, at that). I certainly don't consider most PC/Mac users to be computer literate. They know next to nothing about the system - they've been trained to jump through a few hoops to fulfill a few simple requests, but they don't really know how to USE a computer. For some people, that's okay, I guess.
But you can't call that computer literacy - that's like calling someone who knows 50 English words "literate". They might be able to comprehend and form a few simple sentences, but that doesn't make 'em literate.
Part of the benefit of Unix is that the components of the system are loosely tied together. You get a lot more control of your system, and what's on it - don't want a GUI? Don't need it. Don't want RPC or filesharing? Fine. Unix is an excellent system for some things - surely not for every purpose, but don't diss it.
How is MacOS a good "total" system? The hardware's generally fair to good, but the OS is still in the stone age in many areas. It's got a pretty UI, but coding for it is not as fun as using it. Also, it's QUITE easy to break. Why? No process-to-process protection - any process can scribble all over another process's memory, even the OS's memory. It uses cooperative multitasking for apps - one app can take over the CPU and never let it go, causing CPU starvation. It still bears traces of its roots, all the way back to the original System versions.
BeOS is a lot better. Once again, not perfect, and it's definitely the typical GUI-based OS - you want one feature? You have to take some others, whether you want/need them or not. It's a good OS for multimedia applications (protected memory, preemptive multitasking, good media framework, POSIX-compliant APIs, etc.). But once again, doesn't work for everyone.
You say how users want something that doesn't break - really, they don't care. How could they, considering how many use Windows? Install one app, it can screw up every other app on your system by replacing a DLL with a different, slightly incompatible version. The Registry constantly gets corrupted. It breaks down all the time. Yet users think that's acceptable. However, on my Linux box, I can install things pretty easily without worrying about the OS collapsing under me.. so that argument is right out.
How familiar are you with operating system design? You talk a lot about system design, but you don't seem to really know good system design when you see one.
It's just interesting that the SpecWEB tests showed Linux to be way ahead, yet ZDNet's tests (I still think ZDNet is in M$'s pocket) show Linux to be behind. Who do you trust? Hmm?
Yes, but did we claim that WE are the supreme innovators? No, I don't recall that we did. However, Microsoft is constantly bandying about the term, stating how they're so innovative - yet they can never name anything truly innovative that they've ever done. If you're going to CLAIM that you're an innovator, you better have something to show to PROVE it. Put up or shut up - it's that simple.
Like this would be the FIRST time they've tried to create their own grass-roots movement. It's just that this time, they're not gonna try to deny it. They're going to stand proudly, and not pull any punches, and just say "We think we have a right to do whatever we want, and we're going to do our damnedest to create a movement to affirm that right!"
It's one thing on a PlayStation, where you're programming (pretty much) to the metal. It's another on the Xbox, where you'll have a lot of overhead (Windows 2000 and DirectX, anyone?) to deal with. It's like comparing Palm to Windows CE/PocketPC handhelds - the CE/PocketPC handhelds may be newer with faster processors, but consider which is faster in the general case, for most tasks that you're gonna be doing with the hardware in question - Palms can acheive the same, or more, speed even on slower hardware. Why? Because (a) you're coding a lot closer to the metal on a Palm, and (b) therefore, you lose a lot of the overhead that WinCE/PocketPC entail.
You mean the Xbox? Well.. it's not outperforming ANYTHING yet - considering the fact that one hasn't actually been demoed (at all, as far as we know), so we can't actually compare an Xbox to current consoles. The demos that HAVE been done are on fast PCs or faster hardware, from what I've heard.
Consoles typically aren't upgradable. That's fine by me. But at least usually when they ship, they're fairly high on the technology wave. By the time the Xbox actually SHIPS (late next year?), it'll be so far behind what's current, anyone who knows their consoles won't waste their time.
Well, problem is that the nVidia XFree 4 driver has 2 components: (a) a binary driver module that XFree itself uses (not a problem, since XF4 provides binary compatibility across OSes on the same hardware), and (b) it has a kernel module for Linux that does "helper" work for direct-to-hardware GL stuff. The kernel module would have to be ported (it's available as source, but I don't know what the license is on it)... but also, the GL libraries might be a problem (they're not the standard GL libs that XFree builds). Can FBSD binaries dynamically link to Linux.so's?
The Glide library that is used in XFree 4.x is stripped down for use with DRI. It's certainly cleaner than trying to integrate that entire codebase into the XFree86 tree. XF4 doesn't need/dev/3dfx though - DRI has its own set of dev nodes that it creates/manages.
Well, it's not like there's some particular feature of the Visor that makes it possible to do software-only patches where you can't on the Palm - it's the same software, just on a ROM instead of an EEPROM (flash-ROM). Palm just decided that the flash ROM should be modified, making the fix permanent, instead of adding another piece of software you have to reload if you ever have to reload your Palm.
As others have said, Handspring's decision wasn't one of user convenience, it was a cost-reducing measure.
I assume you have OS 3.5? (Launcher,/i, Version) If you do, on 8 MB units it takes 256 KB of the unit RAM for the heap. So, 8192 - 256 = 7936. OS 3.5 uses a differently-sized heap depending on system RAM size, whereas on OS 3.3, it's always 128 KB (causing my slightly-older Vx to show 8064 KB total RAM).
Ok, I actually installed OS 3.5... it had some nice features, but still felt a little unpolished, so I jumped back to 3.3 for now. Hurry up and get a final 3.5 release ready, Palm!:p
So did my Palm Vx, which according to Palm's site "might" have been one of the affected units. So, at least it doesn't seem that every unit shipped with 8 MB was bad, and hopefull the numbers were as small as Palm is claiming.
Some of us feel that we can at least trust Sun a _little_ bit. I think the majority here will agree with my opinion of Microsoft however - I wouldn't trust Bill Gates & Co. any further than I could throw them. Knowing their past exploits in the world of computer software, we're just waiting to see Microsoft's next move.
Yes, permissions are stored with the inode... but as someone else mentioned, the permissions of containing parent directories also matter so you'd have to look up the containing directories and check permissions on each of them first.
Just with OSS, they end up doing it in public... for all the world to see.
Exactly. I'm sure some of the same things happen inside of corporations pretty frequently - we just don't hear about them. We're human, it's normal. Why get uptight about it?
Well, when you have an API hook specifically for copying files, that's great. But Unix copy tools just open() source, open() destination, read() from source, and write() to destination. So unfortunately, that makes the solution a whole lot more complex.
On Unix/Linux X applications there is, as far as I know, no way to imbed an icon in an execuatble file. If one is even included, it must come along as "icon.xbm" and be put into/usr/share/icons or somewhere.
You mean besides compiling in an XBM/XPM as part of the C source? XPMs are laid out with just that in mind.
Slashdot Mirror
Except for the part where practically every app you install overwrites some DLL that came with Windows or another app - whether it's a newer version or not. With Linux, you have versioned libraries, so you can have different versions of the same library around to accomodate older apps. Also, Unix/Linux definitely assumes more knowledge on the part of the user, but you get an infinitely more flexible system. Macintosh is pretty much designed for dummies. (I'm sorry, but it's true...) Windows is supposed to be end-user-oriented, but with all the shortcomings it has, it's certainly not as user-friendly as it's billed.
Probably because, as someone else noted, to Mac users the application is completely engendered in the GUI. If it doesn't have a pretty GUI, it's probably not worth using, in their estimation. Whereas Linux users (I for one) don't necessarily care as much about a pretty GUI - the app's value is in if it fulfills a need. If it has a GUI, it should be functional, and looking decent is a nice side benefit. To us, a command-line is very useful because that's the kind of system we want - it allows us to use apps and utilities as components to accomplish something. (Whatever that may be.) Whereas with most Mac users, it has to be simple. A command-line is ugly, and it has no pictures. It's not simple, so it's simply not worth doing.
It's all in the mentality of the user, man.
The MacOS system and attitude feels to me like a marketing concept, a billboard...a tool to provide Apple Computer with revenue.
Well, isn't that basically what it is? The OS is made simply to complement their hardware. Apple is, after all, a hardware company. They're definitely not making THAT much money from the OS...
I've heard this point made before. "People just want to be able to use a computer, without having to read 10 thousand page manuals or go through 6 months of training - it's just a tool to them!" Yes, it's a tool, but the problem is the traditional "tool" perspective doesn't work with a computer.
If you have a knife, or a screwdriver, hammer, etc., it has a SIMPLE purpose. It's designed to do one specific thing and do it well. (You can probably substitute one tool for another in certain circumstances, but that's not necessarily a good idea.) I'm sure the medical prototype device you were referring to, also, had a pretty specific purpose. (Correct me if I'm wrong.)
A general-purpose computer can't be thought of in the same way, however, due to its nature. It's a multifaceted beast - it can do a myriad of things, but to get it to do any of them well, you have to have some mastery of the machine. You need to know how to tell it, specifically, what it is you want it to do, and how you want it done. Yes, with little or no training and a pretty GUI to guide, a user can probably do some tasks, using the computer, and do them decently. But they'll never be able to do them well, without being able to actively engage the computer and understand how it works well enough to communicate to it what you want.
Just MHO, but that's simply my take on why you HAVE to be willing to learn to use a computer, and why the "just a tool" mentality is all wrong.
There is no good reason why $_, @_, $@, etc. should be legal variable names in any language. They're pure nonsense. Why couldn't they be given more descriptive names?
... anyone who's tried to show a bash shell to somebody who's never seen an UNIX-style command line but is otherwise highly computer-literate.
Umm. Try 'perldoc perlvar' sometime, you might learn something. (Like that there ARE long aliases for those variables if you want them, it's just a matter of reading.)
This is interesting. How computer-literate is the average Mac or Windows user, really? Not particularly. And why, might I ask? Because they're used to using an OS that tries to eliminate the need for computer literacy (sometimes not doing a particularly good job, at that). I certainly don't consider most PC/Mac users to be computer literate. They know next to nothing about the system - they've been trained to jump through a few hoops to fulfill a few simple requests, but they don't really know how to USE a computer. For some people, that's okay, I guess.
But you can't call that computer literacy - that's like calling someone who knows 50 English words "literate". They might be able to comprehend and form a few simple sentences, but that doesn't make 'em literate.
Part of the benefit of Unix is that the components of the system are loosely tied together. You get a lot more control of your system, and what's on it - don't want a GUI? Don't need it. Don't want RPC or filesharing? Fine. Unix is an excellent system for some things - surely not for every purpose, but don't diss it.
How is MacOS a good "total" system? The hardware's generally fair to good, but the OS is still in the stone age in many areas. It's got a pretty UI, but coding for it is not as fun as using it. Also, it's QUITE easy to break. Why? No process-to-process protection - any process can scribble all over another process's memory, even the OS's memory. It uses cooperative multitasking for apps - one app can take over the CPU and never let it go, causing CPU starvation. It still bears traces of its roots, all the way back to the original System versions.
BeOS is a lot better. Once again, not perfect, and it's definitely the typical GUI-based OS - you want one feature? You have to take some others, whether you want/need them or not. It's a good OS for multimedia applications (protected memory, preemptive multitasking, good media framework, POSIX-compliant APIs, etc.). But once again, doesn't work for everyone.
You say how users want something that doesn't break - really, they don't care. How could they, considering how many use Windows? Install one app, it can screw up every other app on your system by replacing a DLL with a different, slightly incompatible version. The Registry constantly gets corrupted. It breaks down all the time. Yet users think that's acceptable. However, on my Linux box, I can install things pretty easily without worrying about the OS collapsing under me.. so that argument is right out.
How familiar are you with operating system design? You talk a lot about system design, but you don't seem to really know good system design when you see one.
It's just interesting that the SpecWEB tests showed Linux to be way ahead, yet ZDNet's tests (I still think ZDNet is in M$'s pocket) show Linux to be behind. Who do you trust? Hmm?
Yes, but did we claim that WE are the supreme innovators? No, I don't recall that we did. However, Microsoft is constantly bandying about the term, stating how they're so innovative - yet they can never name anything truly innovative that they've ever done. If you're going to CLAIM that you're an innovator, you better have something to show to PROVE it. Put up or shut up - it's that simple.
Like this would be the FIRST time they've tried to create their own grass-roots movement. It's just that this time, they're not gonna try to deny it. They're going to stand proudly, and not pull any punches, and just say "We think we have a right to do whatever we want, and we're going to do our damnedest to create a movement to affirm that right!"
Are you really that surprised?
It's one thing on a PlayStation, where you're programming (pretty much) to the metal. It's another on the Xbox, where you'll have a lot of overhead (Windows 2000 and DirectX, anyone?) to deal with. It's like comparing Palm to Windows CE/PocketPC handhelds - the CE/PocketPC handhelds may be newer with faster processors, but consider which is faster in the general case, for most tasks that you're gonna be doing with the hardware in question - Palms can acheive the same, or more, speed even on slower hardware. Why? Because (a) you're coding a lot closer to the metal on a Palm, and (b) therefore, you lose a lot of the overhead that WinCE/PocketPC entail.
You mean the Xbox? Well.. it's not outperforming ANYTHING yet - considering the fact that one hasn't actually been demoed (at all, as far as we know), so we can't actually compare an Xbox to current consoles. The demos that HAVE been done are on fast PCs or faster hardware, from what I've heard.
Consoles typically aren't upgradable. That's fine by me. But at least usually when they ship, they're fairly high on the technology wave. By the time the Xbox actually SHIPS (late next year?), it'll be so far behind what's current, anyone who knows their consoles won't waste their time.
The existing drivers should work fine. The ABIs are (AFAIK) NOT changing at all.
Well, problem is that the nVidia XFree 4 driver has 2 components: (a) a binary driver module that XFree itself uses (not a problem, since XF4 provides binary compatibility across OSes on the same hardware), and (b) it has a kernel module for Linux that does "helper" work for direct-to-hardware GL stuff. The kernel module would have to be ported (it's available as source, but I don't know what the license is on it)... but also, the GL libraries might be a problem (they're not the standard GL libs that XFree builds). Can FBSD binaries dynamically link to Linux .so's?
The Glide library that is used in XFree 4.x is stripped down for use with DRI. It's certainly cleaner than trying to integrate that entire codebase into the XFree86 tree. XF4 doesn't need /dev/3dfx though - DRI has its own set of dev nodes that it creates/manages.
Well, it's not like there's some particular feature of the Visor that makes it possible to do software-only patches where you can't on the Palm - it's the same software, just on a ROM instead of an EEPROM (flash-ROM). Palm just decided that the flash ROM should be modified, making the fix permanent, instead of adding another piece of software you have to reload if you ever have to reload your Palm.
As others have said, Handspring's decision wasn't one of user convenience, it was a cost-reducing measure.
Reboot cold and lose all data? Don't tell me she never synced?
I assume you have OS 3.5? (Launcher, /i, Version) If you do, on 8 MB units it takes 256 KB of the unit RAM for the heap. So, 8192 - 256 = 7936. OS 3.5 uses a differently-sized heap depending on system RAM size, whereas on OS 3.3, it's always 128 KB (causing my slightly-older Vx to show 8064 KB total RAM).
:p
Ok, I actually installed OS 3.5... it had some nice features, but still felt a little unpolished, so I jumped back to 3.3 for now. Hurry up and get a final 3.5 release ready, Palm!
So did my Palm Vx, which according to Palm's site "might" have been one of the affected units. So, at least it doesn't seem that every unit shipped with 8 MB was bad, and hopefull the numbers were as small as Palm is claiming.
Oh really? I used 'unzip' and ApplixWare, and I can read it just fine. Not that I really care about it that much, but it _does_ work...
At least with Perl, you have the '-w' switch, so you can check for stuff like that. Does C# have the same - why, I think not...
Some of us feel that we can at least trust Sun a _little_ bit. I think the majority here will agree with my opinion of Microsoft however - I wouldn't trust Bill Gates & Co. any further than I could throw them. Knowing their past exploits in the world of computer software, we're just waiting to see Microsoft's next move.
Yes, permissions are stored with the inode... but as someone else mentioned, the permissions of containing parent directories also matter so you'd have to look up the containing directories and check permissions on each of them first.
Just with OSS, they end up doing it in public... for all the world to see.
Exactly. I'm sure some of the same things happen inside of corporations pretty frequently - we just don't hear about them. We're human, it's normal. Why get uptight about it?
Well, when you have an API hook specifically for copying files, that's great. But Unix copy tools just open() source, open() destination, read() from source, and write() to destination. So unfortunately, that makes the solution a whole lot more complex.
On Unix/Linux X applications there is, as far as I know, no way to imbed an icon in an execuatble file. If one is even included, it must come along as "icon.xbm" and be put into /usr/share/icons or somewhere.
You mean besides compiling in an XBM/XPM as part of the C source? XPMs are laid out with just that in mind.