No, actually I was not thinking hard disk files. I assumed that they'd be virtual in-memory files, kind of like shared memory is under Linux. In Linux, when you call gethostbyname(), it directly maps to how the software is designed. In Inferno, the call has to be relayed through the file system (context switch to kernel) which has to relay it to the appropriate code. Even if the file never hits the harddisk (now that would be silly!) it still incurs the overhead of having to have the filesystem code deal with the write and call the appropriate code.
I think treating a device as anything other than a region of memory is pretty silly, because that's exactly what it is. Maybe its just from doing so much DirectX work, but I find stuff that maps to the hardware (like Direct3D) much easier to program for than stuff that gives me abstractions that the author thought was appropriate (OpenGL). Say you're writing a graphics driver. You know that you have to write certain values to certain locations from a certain offset. Say writing 5 to BASE+0x5 results in a video mode change. Under the whole file paradigm, you have to convert this to the ioctl format or a stream based thing, wheras in the memory region way, you could just set 0x5 above the pointer to 5. Also, devices don't exactly have depth. Probaly the deepest tree you'll have in the case of an Inferno device would be that of something like a Voodoo2, where you'd have a root dir, and two files representing texture memory and frame buffer. Lastly, having this overhead doesn't sit well with me. Not only does inferno run everything in a VM (kinda like a Java OS? Last time I checked, Java was barely fast enough for those porn feeds, much less and OS!) but it makes these abstractions that result in a further performance hit. Performance penalties should be optional. Why not have a base API designed for performance, and then wrap these abstractions around that?
That's why I said that OSS people tend to stay away from Windows. I don't think that this is completely deserved, however. Yea, it's nice if the underlying OS shares your values, but I doubt it is the closed-ness of Windows that keeps OSS people from developing on it. I think it is a general resentment (okay, deep seated hate) of anything having to do with Bill or Microsoft. As for my preference, I can see why you like doing backend services on UNIX. The coordination it has between different programs, and all the glue tools available are quite impressive. I am writing a package manager for BeOS (which looks pretty UNIXish in the root FS layout, the userspace programs, and the POSIX API), and have barely written any custom code, just written glue code to bind stuff together. However, I tend to like doing front-end stuff a lot more (graphics and sound) and thus far Windows (actually DirectX) is unmatched for that.
I was reading through the Inferno docs, and I must say, I'm quite impressed. It looks like a very clean and unified architecture. However, does the cleanliness of the design outweigh the performance disadvantages of this? Sure it may make it easier to port, and the whole "everything is a file!" think may make it a more unified design, but in the end is it worth it? Two things. A) Most operating systems only run one major architecture. Portability is good, but excessive portability at the expense of speed is bad. I think Linux strikes a nice balance in this regard, it uses ugly performance code when it has to, but keeps the whole thing pretty portable. Also, according to the Be developers, "there is no such thing as portable code, only code that has been ported." B) Everything is not a file! To some extent, it makes sense, but I never understood the whole file concept. Isn't it much simpler to treat everything as a region of memory? So if you are writing a driver, you simply write to regions of memory starting from a base address rather than doing ioctls, which seem to abstract it to much. Also, when stuff like DNS lookups are done through files, isn't it getting a little silly? Isn't it simpler to map closer to the way the software is actually working? Especially in the cases of stuff like DNS lookups which don't totally make sense being treated as a file. Also, doesn't going through the FS create some overhead? In BeOS a region of shared memory (an "area") is simply a region of memory. You get a pointer to it through the create_area() function, and you tell the OS that you're done with it through delete_area(), kind of like malloc() and free(). In kernel 2.4, it is treated as a file mounted at/var/shm, and means that every access incurs a slight overhead by having to go through the file system.
You have fun developing database servers? (Just kidding) I do stuff for fun too, and graphics on *nix is no fun. Say what you will, but DirectX rocks hard as hell.
There is nothing about Windows that prevents people from sharing code. A Windows developed OSS program is just as free as one developed on Linux. A proprietory Linux program is just as proprietory as one on Windows. However, people who care about Open Source tend to have some religious differences with Bill, or are hard core UNIX nuts. As such, they tend to stay away from Windows.
It is possible under Windows, there are toolkits that wrap the interface (You can even make it look like Motif!) Or you can use something like MFC or OWL instead of Win32. However, toolkits are rarely used because it is more convenient for the user to have all apps look the same. I think this is an important philosophy, because in all truth, the user is more important than the programmer. You only program it once, people have to use it everyday.
I much prefer the highly integrated IDEs for the type of programming that I do. Sure, text mode programming and all that can (at least some people believe that) be more efficiant than an IDE, but it has to be set up right, and switching between programming and debug incurs some overhead. For the graphics stuff (especially with DirectDraw) that I do, I tend to write a small module, then have it crash, fix the bug, recompile, have it crash again, etc. numerous times before it works correctly. For me, it is a tremendous advantage to be able to simply move my mouse to redo the build rather than to switch to a new terminal, hit up bring up the previous command, and then execute my program. Also, VisualStudio offers something that keeps me coming back for more: incremental compiling. If you make a reletivly small change (like one often does in debuging graphics code) it will just change that part and not recompile the whole file, which is much faster. Also, it tends to produce better optimization and support incremental linking (which isn't supported by default in most Linux distro's) which make file size smaller.
True, RedHat is making money, but for a business in RedHat's position, $16mil is a pitance. And a 2.5mil loss is still way to much for a company as established (and old! RedHat is not a startup) as Redhat. I think Be is a bad long term investment too. They still aren't making a profit, but at least they have some new prospects on the horizon. Until RedHat can take advantage of its position as the dominant Linux company.
Having a judge bail you out is not exactly something to be proud of. In fact, the Linux community should be ashamed if MS loses this case, because they'll never know if they won on basis of superior product tactics, or they just had Bill's head handed to them on a silver platter. I strongly believe that current laws don't work too well for computer companies due to the nature of the product. There is nothing about a cable line that prevents competitors from using it, but almost everything makes OSs incompatible with each other. Almost by definition, widespread computing needs a monopoly-class OS.
Speaking of Linux distros, I was recently reading the Microcenter ad (a big chain store) and noticed many Linux distros. Favorites like RedHat, Corel, Debian, TurboLinux, FreeBSD... yes, FreeBSD was listed as a Linux distro. Oh the humanity.
Hey, what is wrong with BSD. I recently erased my Linux partition (yes I know I'm an OS slut) and replaced it with a FreeBSD partition. I installed via FTP, and in general, FBSD seems much less chaotic to me. It's the first UNIX I'm actually thinking of keeping around. The point is, that Dell users would probably be better served by BSD. There are more experianced sysadmins familiar with BSD, and more high-profile sites run BSD. Also, it seems to be much easier to manage and update for the thread-bare sysadmin.
Damn. MS MADE Kerberos what it is. MPEG4 is a seriously kick ass codec. Are you telling me Sonorsen should be sued for keeping its codec (the monopoly on Quicktime por... er... videos) prorietory? And MS is not trying to do anything to Palm. They are simply trying to compete in the market with a higher end product. To tell the truth, I would rather have the power of a WinCE device than the simplicity of a Palm, because I don't have much use for a device that simply keeps shedules. In this case MS really is innovating, trying to get the whole, "PC in your hand" thing going. While it is very effective, palm is simply trying to make a better day planner.
How is this a good long term investment? IT has a shaky, unproven business model, and has yet to turn a profit, even though it completely dominates the commercial Linux market. Think, Linux has 30-something% of the server market, and RedHat is the major commercial vendor in this space. Yet, they still haven't managed to make money off of it (aside from the stock). I seriously think that Linux is not going to make it big through the efforts of companies like RedHat, but more through people just downloading a distribution and contracting with a professional tech support company.
Have you seen the benchmarks? GeForce2 blows away Voodoo5. As for antialiasing, GeForce2 does its antialiasing just about as fast as Voodoo5 4x mode. Plus, GeForce2 has cool lighting and rasterizer effects like per-pixel lighting, bumpmapping, etc, all applied in ONE PASS!
You kidding? Blender has an interface from hell. Also, it doesn't run on BeOS very well because it seems to render the whole preview to a bitmap first them blit that to the screen. (God knows why!)
It just pisses me off that so many/. readers are misinformed about BeOS. Like the guys who don't read the entire articles and miss little things like QuakeII is not SMP aware, so they go out and blaber on/. about bad testing methods. Then there are the guys who don't even research the fact that Voodoo is slower under X4.0 and complain that an older version of X was used on the tests. Under a Linux againt Microsoft story where Linux won, any errors pro-Microsofties made would be quickly pointed out. In the case of BeOS,/. tends to let these things slide. There are a great many people on/. who have no clue about BeOS, much less have used it, but still feel that they should post potentially false information.
MP3s do play in a continuous stream, but remember, you're running 24 of them at a time through filters. Because the OS has to manage so many buffers, and the fact that the filters are constantly accessing the stream, the latency to audio calls is important. And of course RT Linux can do that, but so can most other real time OSs. BeOS so far has the lowest audio latency available on a normal (ie. not real time) OS.
This has nothing to do about me. If you read the official response of the guys who tested this, that's their response. I for one, am ecstatically happy! IE. My words and actions in now way represent BeNews. Also, notice I rarely brought up the subject that BeOS trounced Linux. 90% of my posts are merely to correct/. dumbasses who don't read the article, yet still feel they can post.
It probably never will. However, not only is POSIX supported, but most of the standard configuration methods in/etc, and all the cool development like gcc, cvs, etc, are there.
Not really. Quake II for BeOS has been available since October of 1998. That's a year and 9 months. BeOS 4.0 was released nearly two years ago. Also, it was ported to the old OpenGL implementation when it was quite immature (and BeOS 4.5 was still called BeOS 4.1)
Slashdot Mirror
No, actually I was not thinking hard disk files. I assumed that they'd be virtual in-memory files, kind of like shared memory is under Linux. In Linux, when you call gethostbyname(), it directly maps to how the software is designed. In Inferno, the call has to be relayed through the file system (context switch to kernel) which has to relay it to the appropriate code. Even if the file never hits the harddisk (now that would be silly!) it still incurs the overhead of having to have the filesystem code deal with the write and call the appropriate code.
I think treating a device as anything other than a region of memory is pretty silly, because that's exactly what it is. Maybe its just from doing so much DirectX work, but I find stuff that maps to the hardware (like Direct3D) much easier to program for than stuff that gives me abstractions that the author thought was appropriate (OpenGL). Say you're writing a graphics driver. You know that you have to write certain values to certain locations from a certain offset. Say writing 5 to BASE+0x5 results in a video mode change. Under the whole file paradigm, you have to convert this to the ioctl format or a stream based thing, wheras in the memory region way, you could just set 0x5 above the pointer to 5. Also, devices don't exactly have depth. Probaly the deepest tree you'll have in the case of an Inferno device would be that of something like a Voodoo2, where you'd have a root dir, and two files representing texture memory and frame buffer. Lastly, having this overhead doesn't sit well with me. Not only does inferno run everything in a VM (kinda like a Java OS? Last time I checked, Java was barely fast enough for those porn feeds, much less and OS!) but it makes these abstractions that result in a further performance hit. Performance penalties should be optional. Why not have a base API designed for performance, and then wrap these abstractions around that?
That's why I said that OSS people tend to stay away from Windows. I don't think that this is completely deserved, however. Yea, it's nice if the underlying OS shares your values, but I doubt it is the closed-ness of Windows that keeps OSS people from developing on it. I think it is a general resentment (okay, deep seated hate) of anything having to do with Bill or Microsoft. As for my preference, I can see why you like doing backend services on UNIX. The coordination it has between different programs, and all the glue tools available are quite impressive. I am writing a package manager for BeOS (which looks pretty UNIXish in the root FS layout, the userspace programs, and the POSIX API), and have barely written any custom code, just written glue code to bind stuff together. However, I tend to like doing front-end stuff a lot more (graphics and sound) and thus far Windows (actually DirectX) is unmatched for that.
Small nitpick. QNX is also a(n) UNIX.
I was reading through the Inferno docs, and I must say, I'm quite impressed. It looks like a very clean and unified architecture. However, does the cleanliness of the design outweigh the performance disadvantages of this? Sure it may make it easier to port, and the whole "everything is a file!" think may make it a more unified design, but in the end is it worth it? Two things. /var/shm, and means that every access incurs a slight overhead by having to go through the file system.
A) Most operating systems only run one major architecture. Portability is good, but excessive portability at the expense of speed is bad. I think Linux strikes a nice balance in this regard, it uses ugly performance code when it has to, but keeps the whole thing pretty portable. Also, according to the Be developers, "there is no such thing as portable code, only code that has been ported."
B) Everything is not a file! To some extent, it makes sense, but I never understood the whole file concept. Isn't it much simpler to treat everything as a region of memory? So if you are writing a driver, you simply write to regions of memory starting from a base address rather than doing ioctls, which seem to abstract it to much. Also, when stuff like DNS lookups are done through files, isn't it getting a little silly? Isn't it simpler to map closer to the way the software is actually working? Especially in the cases of stuff like DNS lookups which don't totally make sense being treated as a file. Also, doesn't going through the FS create some overhead? In BeOS a region of shared memory (an "area") is simply a region of memory. You get a pointer to it through the create_area() function, and you tell the OS that you're done with it through delete_area(), kind of like malloc() and free(). In kernel 2.4, it is treated as a file mounted at
You have fun developing database servers? (Just kidding) I do stuff for fun too, and graphics on *nix is no fun. Say what you will, but DirectX rocks hard as hell.
There is nothing about Windows that prevents people from sharing code. A Windows developed OSS program is just as free as one developed on Linux. A proprietory Linux program is just as proprietory as one on Windows. However, people who care about Open Source tend to have some religious differences with Bill, or are hard core UNIX nuts. As such, they tend to stay away from Windows.
It is possible under Windows, there are toolkits that wrap the interface (You can even make it look like Motif!) Or you can use something like MFC or OWL instead of Win32. However, toolkits are rarely used because it is more convenient for the user to have all apps look the same. I think this is an important philosophy, because in all truth, the user is more important than the programmer. You only program it once, people have to use it everyday.
I much prefer the highly integrated IDEs for the type of programming that I do. Sure, text mode programming and all that can (at least some people believe that) be more efficiant than an IDE, but it has to be set up right, and switching between programming and debug incurs some overhead. For the graphics stuff (especially with DirectDraw) that I do, I tend to write a small module, then have it crash, fix the bug, recompile, have it crash again, etc. numerous times before it works correctly. For me, it is a tremendous advantage to be able to simply move my mouse to redo the build rather than to switch to a new terminal, hit up bring up the previous command, and then execute my program. Also, VisualStudio offers something that keeps me coming back for more: incremental compiling. If you make a reletivly small change (like one often does in debuging graphics code) it will just change that part and not recompile the whole file, which is much faster. Also, it tends to produce better optimization and support incremental linking (which isn't supported by default in most Linux distro's) which make file size smaller.
True, RedHat is making money, but for a business in RedHat's position, $16mil is a pitance. And a 2.5mil loss is still way to much for a company as established (and old! RedHat is not a startup) as Redhat. I think Be is a bad long term investment too. They still aren't making a profit, but at least they have some new prospects on the horizon. Until RedHat can take advantage of its position as the dominant Linux company.
Having a judge bail you out is not exactly something to be proud of. In fact, the Linux community should be ashamed if MS loses this case, because they'll never know if they won on basis of superior product tactics, or they just had Bill's head handed to them on a silver platter. I strongly believe that current laws don't work too well for computer companies due to the nature of the product. There is nothing about a cable line that prevents competitors from using it, but almost everything makes OSs incompatible with each other. Almost by definition, widespread computing needs a monopoly-class OS.
Speaking of Linux distros, I was recently reading the Microcenter ad (a big chain store) and noticed many Linux distros. Favorites like RedHat, Corel, Debian, TurboLinux, FreeBSD... yes, FreeBSD was listed as a Linux distro.
Oh the humanity.
Hey, what is wrong with BSD. I recently erased my Linux partition (yes I know I'm an OS slut) and replaced it with a FreeBSD partition. I installed via FTP, and in general, FBSD seems much less chaotic to me. It's the first UNIX I'm actually thinking of keeping around. The point is, that Dell users would probably be better served by BSD. There are more experianced sysadmins familiar with BSD, and more high-profile sites run BSD. Also, it seems to be much easier to manage and update for the thread-bare sysadmin.
Damn. MS MADE Kerberos what it is. MPEG4 is a seriously kick ass codec. Are you telling me Sonorsen should be sued for keeping its codec (the monopoly on Quicktime por... er... videos) prorietory? And MS is not trying to do anything to Palm. They are simply trying to compete in the market with a higher end product. To tell the truth, I would rather have the power of a WinCE device than the simplicity of a Palm, because I don't have much use for a device that simply keeps shedules. In this case MS really is innovating, trying to get the whole, "PC in your hand" thing going. While it is very effective, palm is simply trying to make a better day planner.
How is this a good long term investment? IT has a shaky, unproven business model, and has yet to turn a profit, even though it completely dominates the commercial Linux market. Think, Linux has 30-something% of the server market, and RedHat is the major commercial vendor in this space. Yet, they still haven't managed to make money off of it (aside from the stock). I seriously think that Linux is not going to make it big through the efforts of companies like RedHat, but more through people just downloading a distribution and contracting with a professional tech support company.
Have you seen the benchmarks? GeForce2 blows away Voodoo5. As for antialiasing, GeForce2 does its antialiasing just about as fast as Voodoo5 4x mode. Plus, GeForce2 has cool lighting and rasterizer effects like per-pixel lighting, bumpmapping, etc, all applied in ONE PASS!
You kidding? Blender has an interface from hell. Also, it doesn't run on BeOS very well because it seems to render the whole preview to a bitmap first them blit that to the screen. (God knows why!)
It just pisses me off that so many /. readers are misinformed about BeOS. Like the guys who don't read the entire articles and miss little things like QuakeII is not SMP aware, so they go out and blaber on /. about bad testing methods. Then there are the guys who don't even research the fact that Voodoo is slower under X4.0 and complain that an older version of X was used on the tests. Under a Linux againt Microsoft story where Linux won, any errors pro-Microsofties made would be quickly pointed out. In the case of BeOS, /. tends to let these things slide. There are a great many people on /. who have no clue about BeOS, much less have used it, but still feel that they should post potentially false information.
Great. BeOS has suberb midi handling capabilities too. (Read up on ObjektSynth, a software midi synth with hardware-like resonse times.)
MP3s do play in a continuous stream, but remember, you're running 24 of them at a time through filters. Because the OS has to manage so many buffers, and the fact that the filters are constantly accessing the stream, the latency to audio calls is important. And of course RT Linux can do that, but so can most other real time OSs. BeOS so far has the lowest audio latency available on a normal (ie. not real time) OS.
This has nothing to do about me. If you read the official response of the guys who tested this, that's their response. I for one, am ecstatically happy! IE. My words and actions in now way represent BeNews. Also, notice I rarely brought up the subject that BeOS trounced Linux. 90% of my posts are merely to correct /. dumbasses who don't read the article, yet still feel they can post.
Except Voodoo2 support on XFree4 is slower than in XFree 3.x.
It probably never will. However, not only is POSIX supported, but most of the standard configuration methods in /etc, and all the cool development like gcc, cvs, etc, are there.
Corel Linux doesn't even ship with server stuff, much less enable them by default.
Not really. Quake II for BeOS has been available since October of 1998. That's a year and 9 months. BeOS 4.0 was released nearly two years ago. Also, it was ported to the old OpenGL implementation when it was quite immature (and BeOS 4.5 was still called BeOS 4.1)