Re:Linuxites think this is not news; Neither is 2.
on
BSD Quickies
·
· Score: 1
Hey, 4.5 is news. I never said that either BSD 4 or Linux 2.3.41 was NOT news. I just said that if you think BSD 4 is not news, then kernel 2.3.41 doesn't classify as news either. If you don't think BeOS 4.5 is news, fine. But if you think kernel 2.3.41 IS news while BeOS 4.5 and BSD 4.9 is NOT, then you're a hypocrite. PS. I consider them all news, but kernel 2.3.41 much less so. But it does serve the purpose of keeping people up to date with whats happening with Linux, so I guess its okay.
Linuxites think this is not news; Neither is 2.3.x
on
BSD Quickies
·
· Score: 3
The next time I hear a Linuxite complaining that "there is no real BSD news left" or "this is just advocacy posing as news" whill have the entire printed sourced of kernel 2.3.41 down their throat. I saw a "news" story about kernel 2.3.41 the other day. No earth shattering additions, no hints at a code freeze, nothing. If the BSD 4.0 code freeze is nothing, then should anyone even consider the release of a devel kernel? Or the Linux code freeze? My question is this: Would the same people who don't consider the BSD 4 code freeze news also ignore a Linux 2.4 code freeze? Or an X4.0 code freeze? Or KDE 2.0... I didn't think so.
Half of everything you said did not make sense. The reason that Merced is less clock speed than Alpha is because it has some obscene number of pipelines. Thats the whole concept of EPIC. Second, the EV6s already hit over 100 watts, so it doesn't really matter if merced does. And I seriously doubt Merced is in order. It is a very parallel processor and no one is stupid enough to make it in-order. Merced is made for some very high end, very specific stuff. Take matrix transformations. Such processes are VERY parallel, and benifet much more from the extra pipes than the extra 100-200 MHz. And matrix transforms are heavily used in 3D, so I guess that Merced might be the ultimate 3D rendering machine.
How the hel does layering more GUI effect sercurity and efficiency? Take properly desgned example. The BeOS tracker can respond to serveral messages that tell it to adjust various parameters. Take for example the count lists message. It returns the number of files in a listing. One way to invoke it would be a command line app like so... trackerParams countlistings where trackerParams would be a program that sends a message to tracker and returns the listing. Or you could have a GUI app that sends the same message. If you design is implmented correctly, so security stuff should be in the interface. Tracker gets teh same message wether it is recieved from the command line or from the GUI. The same should be true of other things. You have a web server? It should respond to a specific set of calls and have security built in. It shouldn't know or care wether those calls came from the GUI or from a command line app. In a good design, a GUI shouldn't contain any security code, just GUI code. And second, how does Windows prove GUIs make the system inefficient and insecure? Security with windows is not a issue, its a consumer OS. (NT security is not due to the GUI, but flaws in the security model.) And the GUI is not to blame for the bad efficiency of windows. Hell, the GUI isn't even a part of the OS. Its in explorer.exe which is essentially the window manager. The flaws in windows come not because of the GUI but because of bad programming. Case in point. BeOS is a lot more efficient than Linux, but it is heavily GUI oriented. The reason is that GUI or no GUI has not effect on the core. If the core is secure and efficient, the program will be secure and efficient regardless of wether it is GUI or command line.
Actually there is a reason I equate threads with OO. In an OO system, threads are more easily spawned tranparently to the programmer. My graphics library spawns numerous threads without the programmer ever asking to, and it would be very difficult to do that in C. The threads improve SMP performance, and they improve responsivness. Finally, threads are much easier under BeOS. They are... A. Created automatically most of the time. B. There are extensive messaging functions to communicate between threads. C. BeOS threads are very light. I think it was in the neighbor hood of 10 times lighter than the pThreads in kernel 2.0 ( In terms of switching and thread creation.)
Actually I am a programmer though admittadly not a system programmer. I guess the hard drive access thing was a bit off. I'll stick to graphics examples which I'm more familier with. Say you are writing a program which does hardware accelerated operations with the graphics card. You schedule a blit, and while the blit function is being carried out by the hardware, your program is sitting there doing nothing, waiting for the blit function to return. What BeOS does, on the other hand, is send the call off to a server, which then calls the hardware. During this call, the server thread handling it blocks so it is not running, and your application can go on its way calculating more stuff. Same thing with sound cards as well. Most OSs have async. IO but not very many have async. graphics and sound, which is very helpful considering even a single proc. PC has quite a few parallel components. And second, a BeOS program is much easier to break up into smaller threads. Normally what would a programmer do. Take the path of least resistance and calculate something, then draw the window, all in one thread. In BeOS, its madatory to split this task, both of which take a lot of processor time. So you can display the current frame while calculating the next frame in another thread. This helps a lot on multiprocessor systems, and still helps a uniprocessor system, because when a thread blocks itself, other threads are ready to run. Try running something like TManager someday on your BeOS machine. (I presume you have it considering you're making statements about it.) You'll see that the majority of threads in most apps are constantly running. Its not just theoretical either. BeOS scales very well, and you can seriously feel the power of an 8 proc. BeOS box, even running normal applications.
Actually, BeOS is a microkernel, which means that verything except messaging and parts of the filesystem and drivers are in userspace servers. These servers are still OO. Actually, the BeOS kernel is not in C++ and kernel drivers can't usually be coded in C++. But servers are the main part of the OS, and the OO helps them out a lot. Its fairly pointless to make the kernel OO since in a microkernel, very few apps actually make calls to the kernel
Yes, but when you change the MTU for the modem, it really does make a difference in speed. And there is a reason I compared G3 to Athlon. The leap in spead between G3 and G4 is one of a 2x magnitude at the same clock speed. The same is not true of PII to Athlon. So fine, compare it to PII, which is more than 2.5 years old. The PII is still faster at floating point. And a 700 MHz athlon in the general case is faster than a G4.
I would just like to put in my BeOS side of things here. You people talk about HURD as if it were something new and revolutionary. BeOS predates HURD by one year. Be was formed in 1990, and GNU hadn't even decided on the mach kernel until well into 1991. By 1997, BeOS had reached R3 and had been released on intel, at which time the OS was production quality. BeOS has many of the things the HURD has. It is fully mickrokernel, it has increadible interapp communication, it is not only OO in system design, but in API design, it is designed to be extended without crufting up the system. In addition, it has a fully journaled filesystem with database attributes. (not a buzzword. BeOS never fscks, and when you use the metadata feature for files and the regular expresion searching you'll never want to go back.) It has a very fast messeging system (which I believe is faster than MACH's) it has extensive API support for media, etc. Of course, BeOS did not come up with all of these. The OO idea was pioneered by Next and microkernels have been around a long time. So give credit where its due. BeOS has done most of what HURD does (except some security and abstaction stuff like coding the OS while its running) and his here now. And BeOS too does not deserve all the credit for it. All these ideas have been pioneered and infact successfully implemented before.
Hey, I think BeOS is quite ahead of HURD in ALL respects. (Aside from the prevasive security.) And it isn't a flame. Everything that HURD does, POSIX, Servers, OO,etc. plus a bunch more are already implemented and polished in BeOS. And I think BeOS predateds HURD by a year or two. (Or maybe I'm wrong. I know that the BeOS concept is about '90 or '91. Anyone know when HURD was designed? Either way, OO and Microkernel has been done before. QNX, and most deservedly NextStep (which epitomized OO design, but not microkernel design. The whole BSD system server kinda defeated the purpose.)
OO is not the silver bullet for ANY app. But it makes sense for OSes because of many reasons. (Read my other post above)Second, it is NOT the flavor of the month. It is increadible how closed minded some people are. If it were up to people like you, we would still be programming in ASM. (You think C is low level? Remember when it was just coming out, all the ASM programmers talked about how inefficient a high level language was?) C is good for somethings. C++ is better for a lot of things. Primary things are... 1. C++ is a touch higher level while retaining the low level power of C. 2. C++ is more easily made parallel. A big help considering processors that run two threads at a time aren't to far off. (I may be wrong, but doesn't one of Sun's chips do that?) Even without those processors, consider how much easier it is to implement threads in OO. Wonder why BeOS runs so fast? Its all in the threads. (And the fact that the BeOS programers are gods among men.:) 3. It is easier to maintain IF it is properly coded. 4. The minute one starts using stuff like multiple inheritence it becomes a piece of shit. But that isn't done in BeOS or most OO systems.
So, no, OO is not the silver bullet. But neither is C. PS. ALL those other languages you mentioned are still widely used. LISP and PROLOG in AI, Python is common and PERL is really common. ("You fool there is nothing perl can't do," comes to mind.) Each has its own niche. With good reason too. Its called using the "right tool for the job." Ever heard that before?
Object oriented means that the system uses objects to communicate with servers. And it is FAR superior to non OO systems for many reasons. 1. It naturally fits the server/client model. The app essential "logs on" to the object, which serves as a client to the server. For example, BeOS (which is totally OO) uses several graphics objects to manage the connection to the graphics server. This connection is buffered, and several functions have to have access to the buffer. This is possible in C, but so much more elegant in C++. 2. It allows the system API to be consolidated. Draw() called inside a window can mean different things than Draw() called in a bitmap. (Ideally, this kind of system needs the kind of object services in VisualC++ since remembering the parameters becomes harder.) Not only is this more elegant, it is easier to learn. 3. It allows system APIs to evolve more easily over time. Ever program windows and call the DirectDrawCreateEx or CreateWindowEx functions? They are a waste of code space. You don't need thoe kind of hacks in an OO system. (The functions in IDirectDraw7 and IDirectDraw work differently, but have the same name.) I also think it may reduce code bloat over time since it is so easy to extend an old object by inheriting it in a new one. This way you shave of a lot of overlapping code. 4. It is very condusive to multithreading. Use BeOS for 5 minutes and wonder at the way it can play 12 MP3s in reverse while copying a large file while effortlessly moving through the desktop. The system never feels like it is working hard at all. Part of it is that the OS is very clean and efficient, but its also the fact that these different jobs use different resources. When copying a file, very little processor is required. But if the OS is not heavily multithreaded, the copying will slow down the rest of the machine becase the copy thread is just waiting for the harddrive.
Are you kidding? Apple has sued the ass of a bunch of companies using the PC BIOS. No one "reversed engineered" the PC BIOS. It was under an open patent. IBM did not hand them the design, but the legal lisence the BIOS was under was open. As was the rest of the system. Just a few years ago apple stopped people from making Apple clones. Ever wonder why all those cheap mac clones suddenly dissapeared one day?
There is really no reason why Motif should have to be replaced. Aside from some minor differences, GNOME, KDE and Motif are essentially the same in temrs of interface. (I know GNOME and KDE have frameworks, but thats not my point.) Whatever is standardized next, I just hope it is a scheme that is independant of the widget set. Motif would still be usable now if it weren't so ugly. Make a standard interface, but make the widgets replaceable, so you get the compatibility that comes with standardization, AND get an interface that is visually pleasing to different people.
I think that a lot of people who are critisizing Quartz really don't understand what it's made for. The whole point of putting Quartz into the GUI was not the cool effects, (Though I presonally think they are kinda nifty) but the advantages that the underlying technology provides to users and developers. By basing the GUI on quartz, you gain quite a few things. A. You keep with the cool oh ah thing Jobs is going for. B. You get the user used to Quartz apps, so when future apps use Quartz, it will fit in with the rest of the applications, and the GUI. Other people have done PS before, but nothing as integrated as this. C. You demo our some of the effects Quartz can do. By making users aware of it, you're more likely to get developers to develop for it. D. You get a good GUI that is resolution independant, and has a good foundation. True, some of the asthetic and user interface points need work, but this is a first attempt to base a GUI on a page discription language. They can tweek that part in future releases, but you can't substantially change the GUI foundation in future releases. If they want vector GUIs to succeed, they have to put it into OSX along with all the other new stuff. The user interface can be refined, the foundation cannot. E. Developers get an excellent tool that is well integrated with the rest of the OS.
I don't exactly see many people critizing X just because Athena and Motif look ugly. So yes, Quartz is a major step foreward, and the OS X GUI is pretty revolutionary. The stuff on top IS just candy, and should be treated as such when judging the merits of the GUI.
What if you're using DSL with PPOE? Thats point to point over ethernet. (What a lot of DSL and broadband companies use.) My point was that Apple can't possible account for all of these and just putting a little applet that says (what is you connection speed?) would be better than assuming it knew everything about the users machine and did not need any user input.
He was talking about drivers. A lot of hardware today still puts drivers on a floppy, and to use those you have to scrounge up a floppy drive, transfer it to you iMac, then install the hardware. He was not talking about software, he was talking about drivers. Did you even bother to read the post? Second, oh come ON! I would rather have a floppy. (Say I write a paper and need to take it to school cuz my printers broken. You're not telling me that is a rare occurance?) then save the 18$ it costs to buy the damn thing.
No apple could not have gotten it right for 99.9% of users. That would require 99.9% of users to use either a modem OR a LAN. If you used a modem, and the setting was for ethernet, you got screwed. If you used ethernet, but the setting was suitable for modem, you go screwed. DID YOU NOT EVEN BOTHER TO READ ANY OF THE WORDS AFTER "WINDOWS"? it says that it is huge BECAUSE IT SUITS ETHERNET. BUT PEOPLE WHO USE MODEMS NEED TO BE ABLE TO CHANGE IT. In MacOS you CANNOT DO THAT, SO IF WHAT YOU USE DOES NOT MATCH WHAT THEY WANT YOU TO USE, YOU'RE OUT OF LUCK. Second, who said anything about G4 sucking at floating point? I said the G3 sucked at floating point. Next, consider this. In cracking RC5, a 450MHz G4 is about the same as a 1 GHz Athlon. RC5 is very biased toward G4 because AltiVec is MADE for that kind of processing. It's almost a best case scenario. In a more general case, such as 3D or imaging, does it not make sense that AltiVec would perform at say 70% efficiency, putting it in line with a 700MHz Athlon? Sure, Athlon has 3DNow!, but AltiVec blows it away, no doubt. But in cases where AltiVec is not used at 100% (like most games, 3D apps, photoshop, and UNLIKE best cases such as RC5) The sheer clockspeed of the Athlon ties the game.
It is more integrated because all functions are similar. When an API is designed, a certain designed bias is put into the API. Things are done in a certain way, calls are named in a certain way. Like the whole windows fill out discriptor object then call initializer function metaphor. Or the all function calls in X start with an X. Or wether you Lock() or Grab() something. In Linux different people wrote different parts of the API and thus you have to learn each one. In windows (esp. DirectX) you learn one, then it is a chinch to learn them all. BeOS takes integration to the next level. EVERYTHING looks like it was designed by one guy.
Notice I said that I don't need 400 day uptimes under a load of 500 users. An OS implements a lot of cruft into it to prevent things from crashing. The more likely it is to crash, the faster it is. When you add multiple users into the mix, then there is even more cruft. I'm saying that I would rather have an average of a 20 day uptime and 30% more performace. And it is total bullshit than Windows crashes three times a day. There is a reason why that happens in a corporate environment, but rarely to home users who know what they are doing. CORPERATE PCS ARE REALLY BADLY CONFIGURED. In schools, libraries, offices, everywhere. Their configuration is attrocious! Whenever I reinstall windows (Every two months, I stuff in a CD, click on the batch file, come back two hours later with a brand new system.) I sped 10 minutes configuring it. Make the swap file constant size, set the MTU, turn on DMA on all the drives, set caching to server mode, etc. Thus, my computer only crashes once every week or so. (Unless I'm doing full screen DirectX programming, where every programming error means a reboot) And its not like all I do is word. I have AOL (more taxing on you system than Unreal) running, while rendering a model in Truespace and programming in Visual C++. I don't think I have ever had a crash while it was rendering. Yes windows is unstable, yes it crashes, but most of the time its because of sysadmins who have no clue what they are doing, or when doing something like shutting down (every 1 out of 5 times, Win98 crashes while shutting down.) or installing a device. Anyone of you who put the amount of time it takes just to configure Redhat or Debian, will be able to tweek windows to the point where it only crashes once a week. and for most users, that isn't a big deal. (For your info, I have lost a grand total of 1 document to my computer freezing. Out of the hundreds I have written from my crazed english teacher, I've lost one.)
Actually quite a few people need to set the MTU on their machines. In windows the default MTU is huge because ethernet LANs have low packet loss. But that sucks for the internet where a 1400 something MTU will kill mutliplayer. Thats why there are all these utilities (Win98 SE includes it in the control panel) to change the MTU. And shut up about faster clock!= faster execution. The G3 sucked at floating point and everybody and their uncle knows it. Sure it whooped in integer, but if people actually NEEDED high-perf integer performance, everyone would have bought K6-3s instead of PIIs givin the option. The G4 is supposedly much better, but even theoretically, its max performance at 450MHz is about comparable to the performance of a 700MHz Athlon. Quite a feat for the arch no doubt, but still, the Athlon costs less.
Why should we run Windows over any other OS? There are a bunch of good reasons. The API is more integrated. It supports 3D and media a hell of a lot better. As good as OSS is, EAX and DirectSound and A3D kick its ass. (I know A3D is being ported, but I'm talking now. Same thing for 3D) Its much easier to use. A user does not have to sysadmin his single user box. It has in general higher quality software. (GIMP is good, Photoshop 5.5 is superlative. Blender is okay, 3D Studio kicks its ass. Visual C++ 6 whoops everything on ANY other OS.)These are all very good reasons, and I doubt anyone would consider them "trolling."
There are also good reasons to run UNIX over Windows. It all depends on what you do. I take offense to the fact that Linux users seem to think they only thing people do on computers is sysadmin and program. There are a bunch of people who don't and have no desire to do either. They have good reasons for using windows. Each OS has its own strenghts and weaknesses and people should use what suits them best. Saying that UNIX is the only OS worth running is trolling at its finest. UNIX does NOT suit me. It is too hefty, and has too much cruft. I don't need 400 day uptimes under the load of 500 users. I don't need security, I don't need web serving, I don't need NFS, I don't need cron, I don't need half the daemons that Linux comes with, I don't need remote display through X. All those weigh down my system. They are invaluabe for a server, but useless for a worksation. I use BeOS to do my programming and media stuff. And I keep windows around for programming and games. I keep Linux on my hard drive so I can try some of the new stuff like X4 or whatever. So no, UNIX is not perfect. Neither is BeOS or Windows or anything else. Saying otherwise would be a boldfaced lie.
Why should we run Windows over any other OS? There are a bunch of good reasons. The API is more integrated. It supports 3D and media a hell of a lot better. As good as OSS is, EAX and DirectSound and A3D kick its ass. (I know A3D is being ported, but I'm talking now. Same thing for 3D) Its much easier to use. A user does not have to sysadmin his single user box. It has in general higher quality software. (GIMP is good, Photoshop 5.5 is superlative. Blender is okay, 3D Studio kicks its ass. Visual C++ 6 whoops everything on ANY other OS.)These are all very good reasons, and I doubt anyone would consider them "trolling."
There are also good reasons to run UNIX over Windows. It all depends on what you do. I take offense to the fact that Linux users seem to think they only thing people do on computers is sysadmin and program. There are a bunch of people who don't and have no desire to do either. They have good reasons for using windows. Each OS has its own strenghts and weaknesses and people should use what suits them best. Saying that UNIX is the only OS worth running is trolling at its finest. UNIX does NOT suit me. It is too hefty, and has too much cruft. I don't need 400 day uptimes under the load of 500 users. I don't need security, I don't need web serving, I don't need NFS, I don't need cron, I don't need half the daemons that Linux comes with, I don't need remote display through X. All those weigh down my system. They are invaluabe for a server, but useless for a worksation. I use BeOS to do my programming and media stuff. And I keep windows around for programming and games. I keep Linux on my hard drive so I can try some of the new stuff like X4 or whatever. So no, UNIX is not perfect. Saying anything else would be a boldfaced lie.
I have always wondered why this hasn't been done before! Couldn't the OS or the browser (preferably the OS so other apps could use it) implement some translation services so that content could easily be translated into different langauges? I know for example BeOS already supports UNICODE as its charecter set, so writing in languages that use a different character set shouldn't be hard. I know there is a GPLed translation program so couldn't you implement something along the lines of... Web sites sends text in english. Browser parses words, feeds it through a translator, then displays it in a givin character set. Hell, altavista already does something like that. Anyway, language modules could be implemented under the translator so people could add support for their favorite language into it. It would be a little slower, and you'd end up with stuff like, "he greeted the bloated blue desk" but you'd get (most) of the basic idea across.
Slashdot Mirror
Hey, 4.5 is news. I never said that either BSD 4 or Linux 2.3.41 was NOT news. I just said that if you think BSD 4 is not news, then kernel 2.3.41 doesn't classify as news either. If you don't think BeOS 4.5 is news, fine. But if you think kernel 2.3.41 IS news while BeOS 4.5 and BSD 4.9 is NOT, then you're a hypocrite.
PS. I consider them all news, but kernel 2.3.41 much less so. But it does serve the purpose of keeping people up to date with whats happening with Linux, so I guess its okay.
The next time I hear a Linuxite complaining that "there is no real BSD news left" or "this is just advocacy posing as news" whill have the entire printed sourced of kernel 2.3.41 down their throat. I saw a "news" story about kernel 2.3.41 the other day. No earth shattering additions, no hints at a code freeze, nothing. If the BSD 4.0 code freeze is nothing, then should anyone even consider the release of a devel kernel? Or the Linux code freeze? My question is this: Would the same people who don't consider the BSD 4 code freeze news also ignore a Linux 2.4 code freeze? Or an X4.0 code freeze? Or KDE 2.0... I didn't think so.
Half of everything you said did not make sense.
The reason that Merced is less clock speed than Alpha is because it has some obscene number of pipelines. Thats the whole concept of EPIC. Second, the EV6s already hit over 100 watts, so it doesn't really matter if merced does. And I seriously doubt Merced is in order. It is a very parallel processor and no one is stupid enough to make it in-order. Merced is made for some very high end, very specific stuff. Take matrix transformations. Such processes are VERY parallel, and benifet much more from the extra pipes than the extra 100-200 MHz. And matrix transforms are heavily used in 3D, so I guess that Merced might be the ultimate 3D rendering machine.
How the hel does layering more GUI effect sercurity and efficiency? Take properly desgned example.
The BeOS tracker can respond to serveral messages that tell it to adjust various parameters. Take for example the count lists message. It returns the number of files in a listing. One way to invoke it would be a command line app like so...
trackerParams countlistings
where trackerParams would be a program that sends a message to tracker and returns the listing.
Or you could have a GUI app that sends the same message. If you design is implmented correctly, so security stuff should be in the interface. Tracker gets teh same message wether it is recieved from the command line or from the GUI. The same should be true of other things. You have a web server? It should respond to a specific set of calls and have security built in. It shouldn't know or care wether those calls came from the GUI or from a command line app. In a good design, a GUI shouldn't contain any security code, just GUI code. And second, how does Windows prove GUIs make the system inefficient and insecure? Security with windows is not a issue, its a consumer OS. (NT security is not due to the GUI, but flaws in the security model.) And the GUI is not to blame for the bad efficiency of windows. Hell, the GUI isn't even a part of the OS. Its in explorer.exe which is essentially the window manager. The flaws in windows come not because of the GUI but because of bad programming. Case in point. BeOS is a lot more efficient than Linux, but it is heavily GUI oriented. The reason is that GUI or no GUI has not effect on the core. If the core is secure and efficient, the program will be secure and efficient regardless of wether it is GUI or command line.
Actually there is a reason I equate threads with OO. In an OO system, threads are more easily spawned tranparently to the programmer. My graphics library spawns numerous threads without the programmer ever asking to, and it would be very difficult to do that in C. The threads improve SMP performance, and they improve responsivness. Finally, threads are much easier under BeOS. They are...
A. Created automatically most of the time.
B. There are extensive messaging functions to communicate between threads.
C. BeOS threads are very light. I think it was in the neighbor hood of 10 times lighter than the pThreads in kernel 2.0 ( In terms of switching and thread creation.)
Actually I am a programmer though admittadly not a system programmer. I guess the hard drive access thing was a bit off. I'll stick to graphics examples which I'm more familier with. Say you are writing a program which does hardware accelerated operations with the graphics card. You schedule a blit, and while the blit function is being carried out by the hardware, your program is sitting there doing nothing, waiting for the blit function to return. What BeOS does, on the other hand, is send the call off to a server, which then calls the hardware. During this call, the server thread handling it blocks so it is not running, and your application can go on its way calculating more stuff. Same thing with sound cards as well. Most OSs have async. IO but not very many have async. graphics and sound, which is very helpful considering even a single proc. PC has quite a few parallel components. And second, a BeOS program is much easier to break up into smaller threads. Normally what would a programmer do. Take the path of least resistance and calculate something, then draw the window, all in one thread. In BeOS, its madatory to split this task, both of which take a lot of processor time. So you can display the current frame while calculating the next frame in another thread. This helps a lot on multiprocessor systems, and still helps a uniprocessor system, because when a thread blocks itself, other threads are ready to run. Try running something like TManager someday on your BeOS machine. (I presume you have it considering you're making statements about it.) You'll see that the majority of threads in most apps are constantly running. Its not just theoretical either. BeOS scales very well, and you can seriously feel the power of an 8 proc. BeOS box, even running normal applications.
Actually, BeOS is a microkernel, which means that verything except messaging and parts of the filesystem and drivers are in userspace servers. These servers are still OO. Actually, the BeOS kernel is not in C++ and kernel drivers can't usually be coded in C++. But servers are the main part of the OS, and the OO helps them out a lot. Its fairly pointless to make the kernel OO since in a microkernel, very few apps actually make calls to the kernel
Yes, but when you change the MTU for the modem, it really does make a difference in speed. And there is a reason I compared G3 to Athlon. The leap in spead between G3 and G4 is one of a 2x magnitude at the same clock speed. The same is not true of PII to Athlon. So fine, compare it to PII, which is more than 2.5 years old. The PII is still faster at floating point. And a 700 MHz athlon in the general case is faster than a G4.
I would just like to put in my BeOS side of things here. You people talk about HURD as if it were something new and revolutionary. BeOS predates HURD by one year. Be was formed in 1990, and GNU hadn't even decided on the mach kernel until well into 1991. By 1997, BeOS had reached R3 and had been released on intel, at which time the OS was production quality. BeOS has many of the things the HURD has. It is fully mickrokernel, it has increadible interapp communication, it is not only OO in system design, but in API design, it is designed to be extended without crufting up the system. In addition, it has a fully journaled filesystem with database attributes. (not a buzzword. BeOS never fscks, and when you use the metadata feature for files and the regular expresion searching you'll never want to go back.) It has a very fast messeging system (which I believe is faster than MACH's) it has extensive API support for media, etc. Of course, BeOS did not come up with all of these. The OO idea was pioneered by Next and microkernels have been around a long time. So give credit where its due. BeOS has done most of what HURD does (except some security and abstaction stuff like coding the OS while its running) and his here now. And BeOS too does not deserve all the credit for it. All these ideas have been pioneered and infact successfully implemented before.
Hey, I think BeOS is quite ahead of HURD in ALL respects. (Aside from the prevasive security.) And it isn't a flame. Everything that HURD does, POSIX, Servers, OO,etc. plus a bunch more are already implemented and polished in BeOS. And I think BeOS predateds HURD by a year or two. (Or maybe I'm wrong. I know that the BeOS concept is about '90 or '91. Anyone know when HURD was designed? Either way, OO and Microkernel has been done before. QNX, and most deservedly NextStep (which epitomized OO design, but not microkernel design. The whole BSD system server kinda defeated the purpose.)
OO is not the silver bullet for ANY app. But it makes sense for OSes because of many reasons. (Read my other post above)Second, it is NOT the flavor of the month. It is increadible how closed minded some people are. If it were up to people like you, we would still be programming in ASM. (You think C is low level? Remember when it was just coming out, all the ASM programmers talked about how inefficient a high level language was?) C is good for somethings. C++ is better for a lot of things. Primary things are... :)
1. C++ is a touch higher level while retaining the low level power of C.
2. C++ is more easily made parallel. A big help considering processors that run two threads at a time aren't to far off. (I may be wrong, but doesn't one of Sun's chips do that?) Even without those processors, consider how much easier it is to implement threads in OO. Wonder why BeOS runs so fast? Its all in the threads. (And the fact that the BeOS programers are gods among men.
3. It is easier to maintain IF it is properly coded.
4. The minute one starts using stuff like multiple inheritence it becomes a piece of shit. But that isn't done in BeOS or most OO systems.
So, no, OO is not the silver bullet. But neither is C.
PS. ALL those other languages you mentioned are still widely used. LISP and PROLOG in AI, Python is common and PERL is really common. ("You fool there is nothing perl can't do," comes to mind.)
Each has its own niche. With good reason too. Its called using the "right tool for the job." Ever heard that before?
Object oriented means that the system uses objects to communicate with servers. And it is FAR superior to non OO systems for many reasons.
1. It naturally fits the server/client model. The app essential "logs on" to the object, which serves as a client to the server. For example, BeOS (which is totally OO) uses several graphics objects to manage the connection to the graphics server. This connection is buffered, and several functions have to have access to the buffer. This is possible in C, but so much more elegant in C++.
2. It allows the system API to be consolidated. Draw() called inside a window can mean different things than Draw() called in a bitmap. (Ideally, this kind of system needs the kind of object services in VisualC++ since remembering the parameters becomes harder.) Not only is this more elegant, it is easier to learn.
3. It allows system APIs to evolve more easily over time. Ever program windows and call the DirectDrawCreateEx or CreateWindowEx functions? They are a waste of code space. You don't need thoe kind of hacks in an OO system. (The functions in IDirectDraw7 and IDirectDraw work differently, but have the same name.) I also think it may reduce code bloat over time since it is so easy to extend an old object by inheriting it in a new one. This way you shave of a lot of overlapping code.
4. It is very condusive to multithreading. Use BeOS for 5 minutes and wonder at the way it can play 12 MP3s in reverse while copying a large file while effortlessly moving through the desktop. The system never feels like it is working hard at all. Part of it is that the OS is very clean and efficient, but its also the fact that these different jobs use different resources. When copying a file, very little processor is required. But if the OS is not heavily multithreaded, the copying will slow down the rest of the machine becase the copy thread is just waiting for the harddrive.
Are you kidding? Apple has sued the ass of a bunch of companies using the PC BIOS. No one "reversed engineered" the PC BIOS. It was under an open patent. IBM did not hand them the design, but the legal lisence the BIOS was under was open. As was the rest of the system. Just a few years ago apple stopped people from making Apple clones. Ever wonder why all those cheap mac clones suddenly dissapeared one day?
There is really no reason why Motif should have to be replaced. Aside from some minor differences, GNOME, KDE and Motif are essentially the same in temrs of interface. (I know GNOME and KDE have frameworks, but thats not my point.) Whatever is standardized next, I just hope it is a scheme that is independant of the widget set. Motif would still be usable now if it weren't so ugly. Make a standard interface, but make the widgets replaceable, so you get the compatibility that comes with standardization, AND get an interface that is visually pleasing to different people.
I think that a lot of people who are critisizing Quartz really don't understand what it's made for. The whole point of putting Quartz into the GUI was not the cool effects, (Though I presonally think they are kinda nifty) but the advantages that the underlying technology provides to users and developers. By basing the GUI on quartz, you gain quite a few things.
A. You keep with the cool oh ah thing Jobs is going for.
B. You get the user used to Quartz apps, so when future apps use Quartz, it will fit in with the rest of the applications, and the GUI. Other people have done PS before, but nothing as integrated as this.
C. You demo our some of the effects Quartz can do. By making users aware of it, you're more likely to get developers to develop for it.
D. You get a good GUI that is resolution independant, and has a good foundation. True, some of the asthetic and user interface points need work, but this is a first attempt to base a GUI on a page discription language. They can tweek that part in future releases, but you can't substantially change the GUI foundation in future releases. If they want vector GUIs to succeed, they have to put it into OSX along with all the other new stuff. The user interface can be refined, the foundation cannot.
E. Developers get an excellent tool that is well integrated with the rest of the OS.
I don't exactly see many people critizing X just because Athena and Motif look ugly. So yes, Quartz is a major step foreward, and the OS X GUI is pretty revolutionary. The stuff on top IS just candy, and should be treated as such when judging the merits of the GUI.
What if you're using DSL with PPOE? Thats point to point over ethernet. (What a lot of DSL and broadband companies use.) My point was that Apple can't possible account for all of these and just putting a little applet that says (what is you connection speed?) would be better than assuming it knew everything about the users machine and did not need any user input.
He was talking about drivers. A lot of hardware today still puts drivers on a floppy, and to use those you have to scrounge up a floppy drive, transfer it to you iMac, then install the hardware. He was not talking about software, he was talking about drivers. Did you even bother to read the post? Second, oh come ON! I would rather have a floppy. (Say I write a paper and need to take it to school cuz my printers broken. You're not telling me that is a rare occurance?) then save the 18$ it costs to buy the damn thing.
No apple could not have gotten it right for 99.9% of users. That would require 99.9% of users to use either a modem OR a LAN. If you used a modem, and the setting was for ethernet, you got screwed. If you used ethernet, but the setting was suitable for modem, you go screwed. DID YOU NOT EVEN BOTHER TO READ ANY OF THE WORDS AFTER "WINDOWS"? it says that it is huge BECAUSE IT SUITS ETHERNET. BUT PEOPLE WHO USE MODEMS NEED TO BE ABLE TO CHANGE IT. In MacOS you CANNOT DO THAT, SO IF WHAT YOU USE DOES NOT MATCH WHAT THEY WANT YOU TO USE, YOU'RE OUT OF LUCK. Second, who said anything about G4 sucking at floating point? I said the G3 sucked at floating point. Next, consider this. In cracking RC5, a 450MHz G4 is about the same as a 1 GHz Athlon. RC5 is very biased toward G4 because AltiVec is MADE for that kind of processing. It's almost a best case scenario. In a more general case, such as 3D or imaging, does it not make sense that AltiVec would perform at say 70% efficiency, putting it in line with a 700MHz Athlon? Sure, Athlon has 3DNow!, but AltiVec blows it away, no doubt. But in cases where AltiVec is not used at 100% (like most games, 3D apps, photoshop, and UNLIKE best cases such as RC5) The sheer clockspeed of the Athlon ties the game.
Yea, I wondered about that? Why the hell does that happen?
It is more integrated because all functions are similar. When an API is designed, a certain designed bias is put into the API. Things are done in a certain way, calls are named in a certain way. Like the whole windows fill out discriptor object then call initializer function metaphor. Or the all function calls in X start with an X. Or wether you Lock() or Grab() something. In Linux different people wrote different parts of the API and thus you have to learn each one. In windows (esp. DirectX) you learn one, then it is a chinch to learn them all. BeOS takes integration to the next level. EVERYTHING looks like it was designed by one guy.
Notice I said that I don't need 400 day uptimes under a load of 500 users. An OS implements a lot of cruft into it to prevent things from crashing. The more likely it is to crash, the faster it is. When you add multiple users into the mix, then there is even more cruft. I'm saying that I would rather have an average of a 20 day uptime and 30% more performace. And it is total bullshit than Windows crashes three times a day. There is a reason why that happens in a corporate environment, but rarely to home users who know what they are doing. CORPERATE PCS ARE REALLY BADLY CONFIGURED. In schools, libraries, offices, everywhere. Their configuration is attrocious! Whenever I reinstall windows (Every two months, I stuff in a CD, click on the batch file, come back two hours later with a brand new system.) I sped 10 minutes configuring it. Make the swap file constant size, set the MTU, turn on DMA on all the drives, set caching to server mode, etc. Thus, my computer only crashes once every week or so. (Unless I'm doing full screen DirectX programming, where every programming error means a reboot) And its not like all I do is word. I have AOL (more taxing on you system than Unreal) running, while rendering a model in Truespace and programming in Visual C++. I don't think I have ever had a crash while it was rendering. Yes windows is unstable, yes it crashes, but most of the time its because of sysadmins who have no clue what they are doing, or when doing something like shutting down (every 1 out of 5 times, Win98 crashes while shutting down.) or installing a device. Anyone of you who put the amount of time it takes just to configure Redhat or Debian, will be able to tweek windows to the point where it only crashes once a week. and for most users, that isn't a big deal. (For your info, I have lost a grand total of 1 document to my computer freezing. Out of the hundreds I have written from my crazed english teacher, I've lost one.)
Actually quite a few people need to set the MTU on their machines. In windows the default MTU is huge because ethernet LANs have low packet loss. But that sucks for the internet where a 1400 something MTU will kill mutliplayer. Thats why there are all these utilities (Win98 SE includes it in the control panel) to change the MTU. And shut up about faster clock!= faster execution. The G3 sucked at floating point and everybody and their uncle knows it. Sure it whooped in integer, but if people actually NEEDED high-perf integer performance, everyone would have bought K6-3s instead of PIIs givin the option. The G4 is supposedly much better, but even theoretically, its max performance at 450MHz is about comparable to the performance of a 700MHz Athlon. Quite a feat for the arch no doubt, but still, the Athlon costs less.
>>
Why should we run Windows over any other OS? There are a bunch of good reasons.
The API is more integrated.
It supports 3D and media a hell of a lot better. As good as OSS is, EAX and DirectSound and A3D kick its ass. (I know A3D is being ported, but I'm talking now. Same thing for 3D)
Its much easier to use. A user does not have to sysadmin his single user box.
It has in general higher quality software. (GIMP is good, Photoshop 5.5 is superlative. Blender is okay, 3D Studio kicks its ass. Visual C++ 6 whoops everything on ANY other OS.)These are all very good reasons, and I doubt anyone would consider them "trolling."
There are also good reasons to run UNIX over Windows. It all depends on what you do. I take offense to the fact that Linux users seem to think they only thing people do on computers is sysadmin and program. There are a bunch of people who don't and have no desire to do either. They have good reasons for using windows. Each OS has its own strenghts and weaknesses and people should use what suits them best. Saying that UNIX is the only OS worth running is trolling at its finest. UNIX does NOT suit me. It is too hefty, and has too much cruft. I don't need 400 day uptimes under the load of 500 users. I don't need security, I don't need web serving, I don't need NFS, I don't need cron, I don't need half the daemons that Linux comes with, I don't need remote display through X. All those weigh down my system. They are invaluabe for a server, but useless for a worksation. I use BeOS to do my programming and media stuff. And I keep windows around for programming and games. I keep Linux on my hard drive so I can try some of the new stuff like X4 or whatever. So no, UNIX is not perfect. Neither is BeOS or Windows or anything else. Saying otherwise would be a boldfaced lie.
>>
Why should we run Windows over any other OS? There are a bunch of good reasons.
The API is more integrated.
It supports 3D and media a hell of a lot better. As good as OSS is, EAX and DirectSound and A3D kick its ass. (I know A3D is being ported, but I'm talking now. Same thing for 3D)
Its much easier to use. A user does not have to sysadmin his single user box.
It has in general higher quality software. (GIMP is good, Photoshop 5.5 is superlative. Blender is okay, 3D Studio kicks its ass. Visual C++ 6 whoops everything on ANY other OS.)These are all very good reasons, and I doubt anyone would consider them "trolling."
There are also good reasons to run UNIX over Windows. It all depends on what you do. I take offense to the fact that Linux users seem to think they only thing people do on computers is sysadmin and program. There are a bunch of people who don't and have no desire to do either. They have good reasons for using windows. Each OS has its own strenghts and weaknesses and people should use what suits them best. Saying that UNIX is the only OS worth running is trolling at its finest. UNIX does NOT suit me. It is too hefty, and has too much cruft. I don't need 400 day uptimes under the load of 500 users. I don't need security, I don't need web serving, I don't need NFS, I don't need cron, I don't need half the daemons that Linux comes with, I don't need remote display through X. All those weigh down my system. They are invaluabe for a server, but useless for a worksation. I use BeOS to do my programming and media stuff. And I keep windows around for programming and games. I keep Linux on my hard drive so I can try some of the new stuff like X4 or whatever. So no, UNIX is not perfect. Saying anything else would be a boldfaced lie.
I have always wondered why this hasn't been done before! Couldn't the OS or the browser (preferably the OS so other apps could use it) implement some translation services so that content could easily be translated into different langauges? I know for example BeOS already supports UNICODE as its charecter set, so writing in languages that use a different character set shouldn't be hard. I know there is a GPLed translation program so couldn't you implement something along the lines of...
Web sites sends text in english. Browser parses words, feeds it through a translator, then displays it in a givin character set. Hell, altavista already does something like that. Anyway, language modules could be implemented under the translator so people could add support for their favorite language into it. It would be a little slower, and you'd end up with stuff like, "he greeted the bloated blue desk" but you'd get (most) of the basic idea across.