There is nothing inherently wrong with that, but from a cleanliness point of few it is not very nice. If another option is available, this is also not the nicest way to resolve the problem. We have a court system where there is a blanket (the law) that makes certain cases always come out one way. Usually, it is not handled on a case by case basis. If it was, then the court system would fall into anarchy. I think people generally hate this method for that very reason, and will try to find another, more structured way to do it if possible. However, in this case, I don't really think there is one.
While the very open style of development has been very succesful for Linux, it is not without it's flaws. Because it is open, people who maintain pieces of the code (such as VFS) actually have a lot of power over what happens to that code. In theory they don't, because people can always write their own code, but I don't think there is anybody who is willing to fork the kernel over this issue. Thus, egos and ego clashes get in the way of development. I'm sure this also occurs in the BSD development teams (considering the circumstances behind the split of NetBSD and FreeBSD) but is just less public due to the more closed nature of the development. Actually, I think such development problems are present in every large Open project simply because there is no management breathing down your neck to stop bickering and do something to further development. Given the fact that people will always have egos, and that nobody wants to close up Linux's development, I'm afraid there is probably nothing to be done, other than resolve issues on a case by case basis.
I'm sorry, but you're information is totally wrong. NT is a microkernel, it does messaging, and the OS/2, DOS and POSIX servers are actual servers. True, the Win32 server provides I/O support for the other servers and the microkernel runs drivers and other servers in kernel space, but they are still seperate servers and communicate by passing messages. Read BYTE circa 1993 to read about the introduction of WindowsNT. One issue in particular deals with microkernel OSs and covers WinNT, WorkplaceOS (the planned successor to OS/2), QNX, Chorus, and Taligent. One section in particular about "personalities" tells that NT uses servers to provide the OS/2, DOS, and POSIX personalities.
Things I love about OpenGL: - Great performance. - Rock solid stability (On NT anyway;) - It support BeOS (oh yea, and Linux too.)
Things I hate about OpenGL: - Dumb extansibility model. C'mon, do we need NV_COMBINE_REGISTERS, ARB_COMBINE_REGISTERS, and ATI_COMBINE_REGISTERS? There should be more central control. (What the hell is the ARB doing). - Slow pace of feature add-ons. With a game market moving at this pace, and nVidia incorporating dozens of cool (usefull!) features every 6 months, OpenGL just can't seem to keep up with DirectX. I think Direct3D 8 already outguns OpenGL for standard features. - It still only really usable in Windows, Suns, and SGIs. Argg, what to do! Of course, there is no way in hell I'm going to learn Direct3D, because frankly, the designers were on crack. They have a beautiful extendible model (a set of COM objects) and then they fuck the API to look like this! (Of course you'll have to pry my dead body of DirectDraw, hard to program or not!)
I think the NT guys have the right idea on how to support backwards compatibility with two different OS architectures (don't laugh!) Microkernel OSs (like NT) use servers to provide system services to applications. In NeXT there is a BSD system server running on top of Mach. NT has POSIX, OS/2, DOS, and Win32 servers running on top of the NT kernel. What the MacOS X people should have done is have a BSD/Cocoa server along with a Carbon server running next to it. What they chose to do is layer it instead (Carbon / BSD/Mach). I have a bad feeling that comes more from the macrokernel approach of MacOS than any conscious design decision.
Meta data is a seriously nifty concept if implemented correctly. BeOS has a similar (though much superior, read up on it) system called attributes. Not only does it allow for info such as icon to be stored within an attribute attached to the file, but it allows things like bookmarks to be implmented entirely as attributes. The cool thing about that is that since attributes are indexed by the file system, they are searchable database style! The contacts database is a set of files with attributes, and just by moving a file into a directory you get an instantly searchable database of contacts. Of course, it necessitates some additional stuff. open() can't read attributes (and it probably won't be able to read meta data, an alternate OS call would have to be implemented). Also, you'd have to switch to something like the.zip format because gzip and tar don't preserve attributes or metadata. If it can be done within the Linux architecture, I think it should. ReiserFS is getting database functionality eventually, and if you could connect the two, you could do some nifty tricks. (And isn't that what Linux is all about?:)
Just so you know, the fastest record overall is 1.1 terabits per second over fiber. However, it was done in a labratory with the fiber coiled around pole. As for Qwest, I think these guys are just great. They have tons of fiber and are provide bandwidth to 70% of major cities. If they upgrade there network significantly with these lines, the internet in general should be much less congested.
I have a couple of questions for those using the test kernel. A) By now being a virtual filesystem, has shared memory taken a performance hit? I was in an arguement with another guy in the Inferno post, and I still think that the overhead introduced by making shared memory filesystem based causes a performance hit. B) What about DevFS? How are people going to upgrade to that? Do you just nuke/dev and run a new copy of MAKEDEV? C) (Okay three questions) How's the performance? Some guy was saying that I/O is still terribly slow. I encountered I/O slowdowns (from 11.29MB/sec to 4.5MB/sec on my old harddrive as measured by hdparm) in dev kernels > 2.3.99-pre7, but have not encountered them in pre6 and below. Did something just break there?
How's the speed of ReiserFS? I use ReiserFS on my Mandrake system, but I just got a new hard drive so I can't tell if the speed up is due to that or ReiserFS.
If you consider the windows line to be the same OS, then you need help. Windows NT is a 32 bit microkernel OS with roots in VAX. Windows 95 is a 24 bit (mix of 16 and 32 bit) OS with roots in DOS. One supports DirectX, the other doesn't. One has modern features like asynchronus I/O and the other doesn't. Also, it isn't exactly a great honor be the third fastest growing desktop OS, considering that #1 and #2 are hugely far ahdead of #3. Lastly, this isn't about Linux. If X dies now, the effects won't be felt too terribly (servers don't have much use for X, and Linux isn't on that many desktops yet.) If people wait longer to kill X, we'll be stuck with a system whose capabilities still don't beat Windows GDI, much less a modern system's. If Win 3.0 were killed early and people had moved to OS/2, I think the computing world would have been much happier.
Let's see, asking people to support an organization (BeUnited) whose works are all Open Source and a big help to the BeOS community. Yes of course that's trolling! (Of course, it's not Linux related so on/. it might not be too far from the truth.)
Is there a reason you are trying to be a jackass with that.sig? I think we should add something to moderation rules that troll.sigs should be able to be moderated down. Or am I mistaken and you're trying to draw traffic to the Be site?
No it is an unmitigated disaster. The idea is that new features that can be server side, should be server side. It lowers memory usage (only one copy of anti-aliasing font libraries), it increases performance (especially over a network) and it lets apps automatically take advantage of the feature. BeOS is integrating a new true-type razterizer from Bitstream called FontFusion. Becauese all programs depend on the OS for font support, all programs will automatically take advantage of this feature. This is very important, if you want to retain a good user experience. Also, the fact that it is hard to add anti-aliased fonts is indicative of a larger problem in the system. I find it mind-boggling that the MIT guys decided to let if be extensible from a window manager point of view, but made the imaging model hard to extend. (Of course I doubt they thought people would still use the software in the year 2000!)
Great, all we need now is easier prolifiration of X. This reminds me of a movie I saw yesterday, "8 Heads in a Duffle Bag." The quote most relevant to this news? "Damn, I thought the old battle-ax would never die!" Back on a more serious topic, I think this will result in a faster, more stable X because more people will be able to contribute patches. You really couldn't do that on the release-based system because your code wasn't current enough to write a patch.
Have any of you ever used any of the BSD's on a desktop machine. I thinking of running FreeBSD as one of my OSs, but don't really know if it's worth it. I know that FreeBSD is more stable than Linux, and faster under heavy network loads, but what about day to day usage? Does the network optimization make it a slower desktop OS than Linux? Or is the difference too negligable to notice?
Here you go, hello world in less than 5 lines. //Start helloworld.cpp #include
int WINAPI WinMain(HINSTANCE h, HINSTANCE t, LPSTR cmds, int nCmds) { MessageBox(NULL, "Hello", "World", MB_OK); return 1; } Okay, fine, that was 6 lines. Sure it's one line in Perl, but considering that C has a minimum requirement of 4 lines, this is not that bad. Also, your perl program is a console mode app, while this is a full-fledged windows application. Yes, it takes about 50 lines of code to create a window, but it takes that much in most procedure-based APIs. Programming Win32 is no harder than programming for X for example. It may be even easier, because it is unified, so once you get the mindset, you can use a lot of stuff like networking without having to learn a different API like in Linux. Of course, you can't compare Win32 to GTK+ or Qt, because those are OO APIs and inherently have less setup code. I do agree, though, that MFC is a bitch and only a fool would try to hand code it, but in reality, MFC was designed to be hand coded, it was designed to be computer generated.
True, in the case of DNS it is definitely network traffic. But what about more important syscalls and calls to stuff like graphics or sound libraries? These functions are called many times repeatedly, and often (as in the case of some graphics calls like putpixel) the function call actually takes less time to exectute than the actual function.
Okay, I'm thinking of it as code associated with a name space. However, when you have a function, you actually have a pointer to the memory where that code is, and a function call is simply a jump to those instructions. Under this method, however, the filesystem part of the OS has to step in to decode the reads and writes to that virtual file and turn them into requests for the DNS address. For example, In Linux: You call gethostbyname(). It calls a system trap which jumps to that code inside the kernel (or netoworking library or whatever.) That function then procedes to get the host name and return it. In Inferno: You write something to a virtual file. The Inferno filesystem intercepts the write. It takes a look at what command you are trying to do, takes a look at the stuff you feed it (parameters) and then passes that info onto the networking code in the kernel via a function call. This step of having the kernel intercept the call and decode it is what introduces the overhead. Also, since it is a virtual file, memory writes and reads have to be done than during a funciton call. All this is what introduces the overhead.
Slashdot Mirror
There is nothing inherently wrong with that, but from a cleanliness point of few it is not very nice. If another option is available, this is also not the nicest way to resolve the problem. We have a court system where there is a blanket (the law) that makes certain cases always come out one way. Usually, it is not handled on a case by case basis. If it was, then the court system would fall into anarchy. I think people generally hate this method for that very reason, and will try to find another, more structured way to do it if possible. However, in this case, I don't really think there is one.
Sorry, I meant OpenBSD... I really did ;)
While the very open style of development has been very succesful for Linux, it is not without it's flaws. Because it is open, people who maintain pieces of the code (such as VFS) actually have a lot of power over what happens to that code. In theory they don't, because people can always write their own code, but I don't think there is anybody who is willing to fork the kernel over this issue. Thus, egos and ego clashes get in the way of development. I'm sure this also occurs in the BSD development teams (considering the circumstances behind the split of NetBSD and FreeBSD) but is just less public due to the more closed nature of the development. Actually, I think such development problems are present in every large Open project simply because there is no management breathing down your neck to stop bickering and do something to further development. Given the fact that people will always have egos, and that nobody wants to close up Linux's development, I'm afraid there is probably nothing to be done, other than resolve issues on a case by case basis.
Of course, these issues would still exist, but the whole architecture is made cleaner through the server approach and is just easier to manage.
I'm sorry, but you're information is totally wrong. NT is a microkernel, it does messaging, and the OS/2, DOS and POSIX servers are actual servers. True, the Win32 server provides I/O support for the other servers and the microkernel runs drivers and other servers in kernel space, but they are still seperate servers and communicate by passing messages. Read BYTE circa 1993 to read about the introduction of WindowsNT. One issue in particular deals with microkernel OSs and covers WinNT, WorkplaceOS (the planned successor to OS/2), QNX, Chorus, and Taligent. One section in particular about "personalities" tells that NT uses servers to provide the OS/2, DOS, and POSIX personalities.
Things I love about OpenGL: ;)
- Great performance.
- Rock solid stability (On NT anyway
- It support BeOS (oh yea, and Linux too.)
Things I hate about OpenGL:
- Dumb extansibility model. C'mon, do we need NV_COMBINE_REGISTERS, ARB_COMBINE_REGISTERS, and ATI_COMBINE_REGISTERS? There should be more central control. (What the hell is the ARB doing).
- Slow pace of feature add-ons. With a game market moving at this pace, and nVidia incorporating dozens of cool (usefull!) features every 6 months, OpenGL just can't seem to keep up with DirectX. I think Direct3D 8 already outguns OpenGL for standard features.
- It still only really usable in Windows, Suns, and SGIs.
Argg, what to do! Of course, there is no way in hell I'm going to learn Direct3D, because frankly, the designers were on crack. They have a beautiful extendible model (a set of COM objects) and then they fuck the API to look like this! (Of course you'll have to pry my dead body of DirectDraw, hard to program or not!)
I think the NT guys have the right idea on how to support backwards compatibility with two different OS architectures (don't laugh!) Microkernel OSs (like NT) use servers to provide system services to applications. In NeXT there is a BSD system server running on top of Mach. NT has POSIX, OS/2, DOS, and Win32 servers running on top of the NT kernel. What the MacOS X people should have done is have a BSD/Cocoa server along with a Carbon server running next to it. What they chose to do is layer it instead (Carbon / BSD /Mach). I have a bad feeling that comes more from the macrokernel approach of MacOS than any conscious design decision.
Meta data is a seriously nifty concept if implemented correctly. BeOS has a similar (though much superior, read up on it) system called attributes. Not only does it allow for info such as icon to be stored within an attribute attached to the file, but it allows things like bookmarks to be implmented entirely as attributes. The cool thing about that is that since attributes are indexed by the file system, they are searchable database style! The contacts database is a set of files with attributes, and just by moving a file into a directory you get an instantly searchable database of contacts. Of course, it necessitates some additional stuff. open() can't read attributes (and it probably won't be able to read meta data, an alternate OS call would have to be implemented). Also, you'd have to switch to something like the .zip format because gzip and tar don't preserve attributes or metadata. If it can be done within the Linux architecture, I think it should. ReiserFS is getting database functionality eventually, and if you could connect the two, you could do some nifty tricks. (And isn't that what Linux is all about? :)
Shoot. That should be www.beunited.org. I'm a dumbass.
Just so you know, the fastest record overall is 1.1 terabits per second over fiber. However, it was done in a labratory with the fiber coiled around pole. As for Qwest, I think these guys are just great. They have tons of fiber and are provide bandwidth to 70% of major cities. If they upgrade there network significantly with these lines, the internet in general should be much less congested.
That was a joke. As in ha ha. As in funny... I know 16bit and 32bit don't make 24bit I was trying to make a joke. Some people...
I have a couple of questions for those using the test kernel. /dev and run a new copy of MAKEDEV?
A) By now being a virtual filesystem, has shared memory taken a performance hit? I was in an arguement with another guy in the Inferno post, and I still think that the overhead introduced by making shared memory filesystem based causes a performance hit.
B) What about DevFS? How are people going to upgrade to that? Do you just nuke
C) (Okay three questions) How's the performance? Some guy was saying that I/O is still terribly slow. I encountered I/O slowdowns (from 11.29MB/sec to 4.5MB/sec on my old harddrive as measured by hdparm) in dev kernels > 2.3.99-pre7, but have not encountered them in pre6 and below. Did something just break there?
Since Linux is so open and all, couldn't Reiser just patch VFS itself? Isn't Linux GPL'd to prevent just this sort of thing?
How's the speed of ReiserFS? I use ReiserFS on my Mandrake system, but I just got a new hard drive so I can't tell if the speed up is due to that or ReiserFS.
If you consider the windows line to be the same OS, then you need help. Windows NT is a 32 bit microkernel OS with roots in VAX.
Windows 95 is a 24 bit (mix of 16 and 32 bit) OS with roots in DOS. One supports DirectX, the other doesn't. One has modern features like asynchronus I/O and the other doesn't. Also, it isn't exactly a great honor be the third fastest growing desktop OS, considering that #1 and #2 are hugely far ahdead of #3. Lastly, this isn't about Linux. If X dies now, the effects won't be felt too terribly (servers don't have much use for X, and Linux isn't on that many desktops yet.) If people wait longer to kill X, we'll be stuck with a system whose capabilities still don't beat Windows GDI, much less a modern system's. If Win 3.0 were killed early and people had moved to OS/2, I think the computing world would have been much happier.
I think maybe you confused my .sig as being part of my post? I was talking about XFree86. At least I think I was. Maybe I need to take my pills now...
Let's see, asking people to support an organization (BeUnited) whose works are all Open Source and a big help to the BeOS community. Yes of course that's trolling! (Of course, it's not Linux related so on /. it might not be too far from the truth.)
Then sorry for accusing you of doing otherwise ;)
Is there a reason you are trying to be a jackass with that .sig? I think we should add something to moderation rules that troll .sigs should be able to be moderated down. Or am I mistaken and you're trying to draw traffic to the Be site?
No it is an unmitigated disaster. The idea is that new features that can be server side, should be server side. It lowers memory usage (only one copy of anti-aliasing font libraries), it increases performance (especially over a network) and it lets apps automatically take advantage of the feature. BeOS is integrating a new true-type razterizer from Bitstream called FontFusion. Becauese all programs depend on the OS for font support, all programs will automatically take advantage of this feature. This is very important, if you want to retain a good user experience. Also, the fact that it is hard to add anti-aliased fonts is indicative of a larger problem in the system. I find it mind-boggling that the MIT guys decided to let if be extensible from a window manager point of view, but made the imaging model hard to extend. (Of course I doubt they thought people would still use the software in the year 2000!)
Great, all we need now is easier prolifiration of X. This reminds me of a movie I saw yesterday, "8 Heads in a Duffle Bag." The quote most relevant to this news?
"Damn, I thought the old battle-ax would never die!" Back on a more serious topic, I think this will result in a faster, more stable X because more people will be able to contribute patches. You really couldn't do that on the release-based system because your code wasn't current enough to write a patch.
Have any of you ever used any of the BSD's on a desktop machine. I thinking of running FreeBSD as one of my OSs, but don't really know if it's worth it. I know that FreeBSD is more stable than Linux, and faster under heavy network loads, but what about day to day usage? Does the network optimization make it a slower desktop OS than Linux? Or is the difference too negligable to notice?
Here you go, hello world in less than 5 lines.
//Start helloworld.cpp
#include
int WINAPI WinMain(HINSTANCE h, HINSTANCE t, LPSTR cmds, int nCmds)
{
MessageBox(NULL, "Hello", "World", MB_OK);
return 1;
}
Okay, fine, that was 6 lines. Sure it's one line in Perl, but considering that C has a minimum requirement of 4 lines, this is not that bad. Also, your perl program is a console mode app, while this is a full-fledged windows application. Yes, it takes about 50 lines of code to create a window, but it takes that much in most procedure-based APIs. Programming Win32 is no harder than programming for X for example. It may be even easier, because it is unified, so once you get the mindset, you can use a lot of stuff like networking without having to learn a different API like in Linux. Of course, you can't compare Win32 to GTK+ or Qt, because those are OO APIs and inherently have less setup code. I do agree, though, that MFC is a bitch and only a fool would try to hand code it, but in reality, MFC was designed to be hand coded, it was designed to be computer generated.
True, in the case of DNS it is definitely network traffic. But what about more important syscalls and calls to stuff like graphics or sound libraries? These functions are called many times repeatedly, and often (as in the case of some graphics calls like putpixel) the function call actually takes less time to exectute than the actual function.
Okay, I'm thinking of it as code associated with a name space. However, when you have a function, you actually have a pointer to the memory where that code is, and a function call is simply a jump to those instructions. Under this method, however, the filesystem part of the OS has to step in to decode the reads and writes to that virtual file and turn them into requests for the DNS address. For example,
In Linux: You call gethostbyname(). It calls a system trap which jumps to that code inside the kernel (or netoworking library or whatever.) That function then procedes to get the host name and return it.
In Inferno: You write something to a virtual file. The Inferno filesystem intercepts the write. It takes a look at what command you are trying to do, takes a look at the stuff you feed it (parameters) and then passes that info onto the networking code in the kernel via a function call. This step of having the kernel intercept the call and decode it is what introduces the overhead. Also, since it is a virtual file, memory writes and reads have to be done than during a funciton call. All this is what introduces the overhead.