Now honestly, do you need a computer processor running at 2.5GHZ if all you are doing is typing on/. or surfing for p0rn? >>>>>>>>> Just wait until KDE 4 and GNOME 3 come out and ask that question again...
Is it just me, or could the rise of Linux (and thus open source software in general) make x86 significantly less important? On my system, there is only once piece of software (NVdriver) that isn't open source. Thus, in theory, it would be easy for me to move to another architecture with no more pain than simply recompiling my distro (which I'm doing ATM on my other machine anyway;) Now, if only there were some cheap alternative arch chips that actually outperformed x86!
I remember hearing that due to its tiny die size (104 square millimeters) Clawhammer would be a desktop/mobile part. If that's true, I can't wait to get a high-performance 64-bit notebook!
Hmm, allowing a user to mount a filesystem and allowing them to write their own is something of a strech, no? Exactly how is this function used often enough to be an actual feature rather than a useless novelty?
Here is my suggestion for the Windows install program to make this "not reading the manual" thing go away. Before the user is allowed to log in for the first time, he would have to complete a quiz about the contents of the manual. The first question would be something like "what is the clock latency of the BSR instruction on the Pentium Pro?" Answering this question right would allow REAL users to skip the rest of the quiz. You know it's a great idea! Tell MS:
e-mail: mailto:mswish@microsoft.com fax: (425) 936-7329 post:
Microsoft Corporation
Attn. Microsoft Wish Program
One Microsoft Way
Redmond, WA 98052-6399
Dude. If you do a daily backups, a filesystem crash is nothing. Especially compared to the fuzzy feeling you get submitting detailed bug-reports to the kernel devs so they can make Linux better. You guys are starting to sound liky mopey Windows users!
PS> I have a spare comp sitting around that I do a daily data-sync with. Cheap, fast, effortless backup!
Supposed to be hard, I didn't say which way I felt. I was just giving information. Personally, the OS X kernel design makes me cringe. Too many different, unrelated technologies (Mac, UNIX, NeXT, Mach, obj-c, c, c++, java), in the core system*, a rather dumb kernel design (removes the benefits of a microkernel by putting a single system server (instead of multiple independent ones) in kernel space, where they can stomp on each other, while still incurring the overhead of message passing. There are some nifty bits, like Quartz Extreme (hardware accelerated vector GUI, about time) and the mix of UNIX and a good GUI system, but overall I'd prefer it either on a real microkernel architecture (ala QNX), using something nicer than Mach, perhaps that C++ L4 kernel, or on a full monolithic kernel like FreeBSD.
*> Note, I don't think the inclusion of all those technologies is bad, but its too far in the core. There's no architectural coherence to the design. Also, as for the languages, again, having them as an option is fine, but different parts of the API use different languages, which is irritating.
Don't be daft. Actually read about the OS-X design before talking about it! The Mach microkernel is not a full kernel in the sense that Linux is. It provides a minimum of functionality. It requires external servers to provide much of the traditional functionality of a kernel. In OS-X (as in NeXT) the external server takes the form of a monolithic BSD system server. In other words, a standard BSD monolithic kernel is altered to run as a server on top of Mach. Unlike most microkernels, OS-X puts its system server in kernel space, which eliminates many benifets of the microkernel design (ie. better protection between kernel components). In OS X, the BSD system server is based on a customized 4.4BSD-lite2 kernel with many parts (like the whole networking infrastructure) thrown in from various BSD OSs, primarly FreeBSD 3.2. In OS-X 10.2, this kernel adopts a bunch of code from FreeBSD 4.4. To satisfy your curiousity, here's the dirt from Apple itself: http://developer.apple.com/darwin/history.html. Read the WHOLE thing. I'm not going to tell your where in the page it is, because reading is good for you.
Its really not their fault. Its users like you who insist on backwards compatibility. They originally put the words at the end (where normal stuff wouldn't interfere) but when they extended the word, the bits wound up in the middle. If you think that's bad, try programming an IDE controller directly. The sector address is broken into three or four parts scattered across 64 bits. Same thing for the GDT entries.
The architecture of the Hurd (not to be confused with the implementation) gives users a lot more freedom than any UNIX-based system. For example, UNIX will not let you mount a loopback encrypted filesystem unless you are root (or without bugging root to frob/etc/fstab, which he/she probably won't want to do), even if the encrypted file is owned by you, in your own directory and you want to mount it within your own home directory. This is something that the architecture prevents you from doing, so no UNIX implementation will ever let you do that (without a heavy dose of magic). Allowing stuff like that is one of the architectural features of the Hurd. >>>>>>>> Praytell, exactly what architectural features (technical reason, please) does Hurd have that allow it to allow users to mount encrypted filesystems? It seems to me like its a policy decision in UNIX kernels, not a technical one.
Porting, and supporting 56k modems are just implementation details, and have nothing to do with the architecture, which is what RMS is talking about.
Its like a bunch of car bores sitting in a bar bullshitting for hours about webber carbs vs bosch jetronic. >>>>>>>>>>> Here's your profile: You use AOL. You're VCR blinks 12:00 All you're Windows ME software still has the default settings. You don't do your own oil changes. You call a handyman whenever something leaks or breaks or burns. You've never read the instruction manual to anything you own. In total, you're a complete marshmellow who doesn't like to get his hands dirty. Some people like tweaking, whether on cars or computers. More power to them!
Couple of problems with that. Time really isn't divided into discrete intervals. If you look at theories that incorporate virtual particles, then you have processes that exist on time scales that are by definition undetectable according to Heisenburg's principle. Second, those forces you mention are hardly fundemental. First, there is the fact that electromagnetic and weakforce have already been shown to be just two facets of the electro-weak force, and second, if you look at theories that say that these forces are transmitted via carrier particles, then you've got to look at the processes that govern *those* particles. In reality, there is nothing that says the universe should be simple. Humans strive for it because it's easy to understand, but there's an equal chance of the universe being infinately simple, infinately complex, or something in between.
Yes they will. If only because you can make Linux use workarounds like high-mem (instead of mapping in all physical memory) for only $200 on pricewatch.
That's what I said: the video driver (i.e., on Linux, the thing that does the mapping and switching) >>>>>>> Except its not! The only part of whole display system that's in the kernel is the part that alters the X server's TSS so it can use the I/O ports of the graphics hardware. This is unlike other OSs (even other ones with client/server archs) where an actual graphics driver, that does stuff like initialization, handling interrupts, etc, runs in the kernel. The main weakness with X's approach is that because *no* part of the graphics driver is in the kernel, certain facillities of the card cannot be taken advantage of. DRI (and NVIDIA's kernel driver) fix this by putting a little bit of the graphics driver in the kernel, but both are rather limited in the range of hardware they support, and only really affect 3D operation.
Qt is slower on X11 than on Windows because Qt ignores most of the server-side facilities that X offers. The "crappy design" there is Qt, not X11, and it mostly means that the authors of Qt just didn't want to bother doing a high-quality X11 implementation: Windows apparently matters more to them. Furthermore, on Windows, the "toolkit" isn't server side either: the display server runs in the kernel, and Qt runs in user space. >>>>>>> Hmm. If that's the case, then X's design is so borked that implementing toolkit functionality server-side is too difficult to get working. There is no major toolkit that puts an appreciable amount of code server-side. This is one of the big things Berlin is trying to solve. As for the Windows case, it's hard to tell. The GDI spec is just the call interface to gdi32.dll. How much of the GDI is implemented in userspace, is uncertain. It is entirely possible that gdi32.dll maps the graphics driver into the application and implements accelerated drawing in userspace. BeOS had an API that worked this way, btw.
I'm not sure what you mean by "before". Windows was written that way. X11 had a client/server architecture from the start and has always worked well with it. Windows is the latecomer, and it still isn't very good at it. >>>>>>> No, I should have said "in the past." I'm talking about the standard WIMP's that have been around for years, basically moving bitmaps around the screen and drawing lines and pixels. Now, the communication latency isn't as important anymore because a lot of overhead goes into packaging objects for the API to begin with.
As I was saying, X11 got it right from the start because X11 didn't assume that any program can just bash pixels in the frame buffer. Windows is playing catch-up >>>>>>> Oh please. The people who designed X never had any clue that 3D hardware would eventually come to their rescue and render the terrible latency in the interface a moot issue. Otherwise, they would have provisioned the system with something like DRI to begin with. Windows is not playing catch up at all in this case. Windows did it right the first time. It specified the drawing API as a set of procedures supported by gdi.dll, nothing more. They've got the freedom to implement their graphics engine however they bloody want to, without being restricted to a 20-year old protocol like X. And no, extensions don't help, because app must be specifically compiled to use them. Extensions violate every principle of OS transparency out there. Take a look at DirectX for an interface that got backwards compatibility correct. Just code your apps for the interface, and generations of hardware can go by and you're app will automatically support new advances.
The video drivers are in the kernel. The drawing and acceleration is in the display server. >>>>> Except its not. For almost all cards (NVIDIA and its kernel driver nonwithstanding) the whole driver is in userspace, acessing the hardware via user-mapped I/O ports. This isn't the ideal situation, because for the absolute best performance, you need some stuff in the kernel (which DRI does, but DRI support is rather limited and only for 3D).
The toolkit is in the application. >>> That's a crappy design. Its more flexible, but its faster to have the toolkit server-side. That's why Qt (and GTK+) on X is slower than Qt on Windows. It basically uses X as a way to move bitmaps around the screen, which isn't the best (or fastest) way to use X. If the toolkit was in the sever, communication between the client and server would be limited to a much higher level (and thus low bandwidth) protocol.
As for windows and MacOS becoming more like X, that's only half true. Windows has the GDI in the kernel, unlike X, which is in userspace (personally, I think that's okay, I mean networking is pretty big too, and that's in the kernel). Quartz is slow as hell, so that's a bad example. Either way, client/server archs are becoming more practical. Before, when basically everything was simple blits or pixel plotting, the latency of individual operations was critical. These days, with OpenGL serving as the support for the GUI (see Longhorn and Jaguar) clients have to package up command anyway (vertex buffers, display lists, etc) and each operation takes comparitvely longer than a single PutPixel(). Thus, the latency of the communication isn't as much of a factor anymore.
Hmm, MacOS isn't geeky, it's grognardy. It caters to an older generation of geeks who still think Mach is cool. BeOS is a more hip geeky, catering to the fresh young people who think prevasive multithreading and transparent SMP are where its at.
Actually, Intel C++ 6.0 and GCC 3.1 (out real soon now) should both support almost all of the ABI. Intel says you can link ICC-compiled stuff to GCC compiled stuff now. It seems to work for some basic code so far, but I haven't tried anything complex yet.
So you like the naked sharp spinning things because the pending death concentrates the mind? You're perverse if you don't mind me saying. >>>> Umm, it's actually scientfic fact that sharp spinning things concentrate the mind. Thing about it: when are you most attentive? Going 95mph on the freeway, or sitting in traffic going 15mph? Danger does sharpen attention.
Slashdot Mirror
Now honestly, do you need a computer processor running at 2.5GHZ if all you are doing is typing on /. or surfing for p0rn?
>>>>>>>>>
Just wait until KDE 4 and GNOME 3 come out and ask that question again...
Is it just me, or could the rise of Linux (and thus open source software in general) make x86 significantly less important? On my system, there is only once piece of software (NVdriver) that isn't open source. Thus, in theory, it would be easy for me to move to another architecture with no more pain than simply recompiling my distro (which I'm doing ATM on my other machine anyway ;) Now, if only there were some cheap alternative arch chips that actually outperformed x86!
I remember hearing that due to its tiny die size (104 square millimeters) Clawhammer would be a desktop/mobile part. If that's true, I can't wait to get a high-performance 64-bit notebook!
Hmm, allowing a user to mount a filesystem and allowing them to write their own is something of a strech, no? Exactly how is this function used often enough to be an actual feature rather than a useless novelty?
Here is my suggestion for the Windows install program to make this "not reading the manual" thing go away. Before the user is allowed to log in for the first time, he would have to complete a quiz about the contents of the manual. The first question would be something like "what is the clock latency of the BSR instruction on the Pentium Pro?" Answering this question right would allow REAL users to skip the rest of the quiz. You know it's a great idea! Tell MS:
e-mail: mailto:mswish@microsoft.com
fax: (425) 936-7329
post:
Microsoft Corporation
Attn. Microsoft Wish Program
One Microsoft Way
Redmond, WA 98052-6399
Dude. If you do a daily backups, a filesystem crash is nothing. Especially compared to the fuzzy feeling you get submitting detailed bug-reports to the kernel devs so they can make Linux better. You guys are starting to sound liky mopey Windows users!
PS> I have a spare comp sitting around that I do a daily data-sync with. Cheap, fast, effortless backup!
Supposed to be hard, I didn't say which way I felt. I was just giving information. Personally, the OS X kernel design makes me cringe. Too many different, unrelated technologies (Mac, UNIX, NeXT, Mach, obj-c, c, c++, java), in the core system*, a rather dumb kernel design (removes the benefits of a microkernel by putting a single system server (instead of multiple independent ones) in kernel space, where they can stomp on each other, while still incurring the overhead of message passing. There are some nifty bits, like Quartz Extreme (hardware accelerated vector GUI, about time) and the mix of UNIX and a good GUI system, but overall I'd prefer it either on a real microkernel architecture (ala QNX), using something nicer than Mach, perhaps that C++ L4 kernel, or on a full monolithic kernel like FreeBSD.
*> Note, I don't think the inclusion of all those technologies is bad, but its too far in the core. There's no architectural coherence to the design. Also, as for the languages, again, having them as an option is fine, but different parts of the API use different languages, which is irritating.
Don't be daft. Actually read about the OS-X design before talking about it! The Mach microkernel is not a full kernel in the sense that Linux is. It provides a minimum of functionality. It requires external servers to provide much of the traditional functionality of a kernel. In OS-X (as in NeXT) the external server takes the form of a monolithic BSD system server. In other words, a standard BSD monolithic kernel is altered to run as a server on top of Mach. Unlike most microkernels, OS-X puts its system server in kernel space, which eliminates many benifets of the microkernel design (ie. better protection between kernel components). In OS X, the BSD system server is based on a customized 4.4BSD-lite2 kernel with many parts (like the whole networking infrastructure) thrown in from various BSD OSs, primarly FreeBSD 3.2. In OS-X 10.2, this kernel adopts a bunch of code from FreeBSD 4.4. To satisfy your curiousity, here's the dirt from Apple itself: http://developer.apple.com/darwin/history.html. Read the WHOLE thing. I'm not going to tell your where in the page it is, because reading is good for you.
Its really not their fault. Its users like you who insist on backwards compatibility. They originally put the words at the end (where normal stuff wouldn't interfere) but when they extended the word, the bits wound up in the middle. If you think that's bad, try programming an IDE controller directly. The sector address is broken into three or four parts scattered across 64 bits. Same thing for the GDT entries.
36-bit physical, 32-bit logical on P6+. Never understood that. You have to use "memory" windows to access different 4GB chunks of the 64GB space.
The architecture of the Hurd (not to be confused with the implementation) gives users a lot more freedom than any UNIX-based system. For example, UNIX will not let you mount a loopback encrypted filesystem unless you are root (or without bugging root to frob /etc/fstab, which he/she probably won't want to do), even if the encrypted file is owned by you, in your own directory and you want to mount it within your own home directory. This is something that the architecture prevents you from doing, so no UNIX implementation will ever let you do that (without a heavy dose of magic). Allowing stuff like that is one of the architectural features of the Hurd.
>>>>>>>>
Praytell, exactly what architectural features (technical reason, please) does Hurd have that allow it to allow users to mount encrypted filesystems? It seems to me like its a policy decision in UNIX kernels, not a technical one.
Porting, and supporting 56k modems are just implementation details, and have nothing to do with the architecture, which is what RMS is talking about.
Its like a bunch of car bores sitting in a bar bullshitting for hours about
webber carbs vs bosch jetronic.
>>>>>>>>>>>
Here's your profile:
You use AOL.
You're VCR blinks 12:00
All you're Windows ME software still has the default settings.
You don't do your own oil changes.
You call a handyman whenever something leaks or breaks or burns.
You've never read the instruction manual to anything you own.
In total, you're a complete marshmellow who doesn't like to get his hands dirty.
Some people like tweaking, whether on cars or computers. More power to them!
When something like this comes along and everybody gets to show their mad multiplication/division skills?
Actually, no. The sat might be broadcasting 100 30mb/sec channels, but each link is only 30mb/sec.
Couple of problems with that. Time really isn't divided into discrete intervals. If you look at theories that incorporate virtual particles, then you have processes that exist on time scales that are by definition undetectable according to Heisenburg's principle. Second, those forces you mention are hardly fundemental. First, there is the fact that electromagnetic and weakforce have already been shown to be just two facets of the electro-weak force, and second, if you look at theories that say that these forces are transmitted via carrier particles, then you've got to look at the processes that govern *those* particles. In reality, there is nothing that says the universe should be simple. Humans strive for it because it's easy to understand, but there's an equal chance of the universe being infinately simple, infinately complex, or something in between.
It's DEVELOPMENT kernel you Micro$oft flunky...
Yes they will. If only because you can make Linux use workarounds like high-mem (instead of mapping in all physical memory) for only $200 on pricewatch.
That's what I said: the video driver (i.e., on Linux, the thing that does the mapping and switching)
>>>>>>>
Except its not! The only part of whole display system that's in the kernel is the part that alters the X server's TSS so it can use the I/O ports of the graphics hardware. This is unlike other OSs (even other ones with client/server archs) where an actual graphics driver, that does stuff like initialization, handling interrupts, etc, runs in the kernel. The main weakness with X's approach is that because *no* part of the graphics driver is in the kernel, certain facillities of the card cannot be taken advantage of. DRI (and NVIDIA's kernel driver) fix this by putting a little bit of the graphics driver in the kernel, but both are rather limited in the range of hardware they support, and only really affect 3D operation.
Qt is slower on X11 than on Windows because Qt ignores most of the server-side facilities that X offers. The "crappy design" there is Qt, not X11, and it mostly means that the authors of Qt just didn't want to bother doing a high-quality X11 implementation: Windows apparently matters more to them. Furthermore, on Windows, the "toolkit" isn't server side either: the display server runs in the kernel, and Qt runs in user space.
>>>>>>>
Hmm. If that's the case, then X's design is so borked that implementing toolkit functionality server-side is too difficult to get working. There is no major toolkit that puts an appreciable amount of code server-side. This is one of the big things Berlin is trying to solve. As for the Windows case, it's hard to tell. The GDI spec is just the call interface to gdi32.dll. How much of the GDI is implemented in userspace, is uncertain. It is entirely possible that gdi32.dll maps the graphics driver into the application and implements accelerated drawing in userspace. BeOS had an API that worked this way, btw.
I'm not sure what you mean by "before". Windows was written that way. X11 had a client/server architecture from the start and has always worked well with it. Windows is the latecomer, and it still isn't very good at it.
>>>>>>>
No, I should have said "in the past." I'm talking about the standard WIMP's that have been around for years, basically moving bitmaps around the screen and drawing lines and pixels. Now, the communication latency isn't as important anymore because a lot of overhead goes into packaging objects for the API to begin with.
As I was saying, X11 got it right from the start because X11 didn't assume that any program can just bash pixels in the frame buffer. Windows is playing catch-up
>>>>>>>
Oh please. The people who designed X never had any clue that 3D hardware would eventually come to their rescue and render the terrible latency in the interface a moot issue. Otherwise, they would have provisioned the system with something like DRI to begin with. Windows is not playing catch up at all in this case. Windows did it right the first time. It specified the drawing API as a set of procedures supported by gdi.dll, nothing more. They've got the freedom to implement their graphics engine however they bloody want to, without being restricted to a 20-year old protocol like X. And no, extensions don't help, because app must be specifically compiled to use them. Extensions violate every principle of OS transparency out there. Take a look at DirectX for an interface that got backwards compatibility correct. Just code your apps for the interface, and generations of hardware can go by and you're app will automatically support new advances.
The video drivers are in the kernel. The drawing and acceleration is in the display server.
>>>>>
Except its not. For almost all cards (NVIDIA and its kernel driver nonwithstanding) the whole driver is in userspace, acessing the hardware via user-mapped I/O ports. This isn't the ideal situation, because for the absolute best performance, you need some stuff in the kernel (which DRI does, but DRI support is rather limited and only for 3D).
The toolkit is in the application.
>>>
That's a crappy design. Its more flexible, but its faster to have the toolkit server-side. That's why Qt (and GTK+) on X is slower than Qt on Windows. It basically uses X as a way to move bitmaps around the screen, which isn't the best (or fastest) way to use X. If the toolkit was in the sever, communication between the client and server would be limited to a much higher level (and thus low bandwidth) protocol.
As for windows and MacOS becoming more like X, that's only half true. Windows has the GDI in the kernel, unlike X, which is in userspace (personally, I think that's okay, I mean networking is pretty big too, and that's in the kernel). Quartz is slow as hell, so that's a bad example. Either way, client/server archs are becoming more practical. Before, when basically everything was simple blits or pixel plotting, the latency of individual operations was critical. These days, with OpenGL serving as the support for the GUI (see Longhorn and Jaguar) clients have to package up command anyway (vertex buffers, display lists, etc) and each operation takes comparitvely longer than a single PutPixel(). Thus, the latency of the communication isn't as much of a factor anymore.
Hmm, MacOS isn't geeky, it's grognardy. It caters to an older generation of geeks who still think Mach is cool. BeOS is a more hip geeky, catering to the fresh young people who think prevasive multithreading and transparent SMP are where its at.
sigh... Maybe I was too subtle?
Perhelia? Sounds painful...
Actually, Intel C++ 6.0 and GCC 3.1 (out real soon now) should both support almost all of the ABI. Intel says you can link ICC-compiled stuff to GCC compiled stuff now. It seems to work for some basic code so far, but I haven't tried anything complex yet.
Slashdot drops the symbol when posting as HTML ;)
So you like the naked sharp spinning things because the pending death concentrates the mind? You're perverse if you don't mind me saying.
>>>>
Umm, it's actually scientfic fact that sharp spinning things concentrate the mind. Thing about it: when are you most attentive? Going 95mph on the freeway, or sitting in traffic going 15mph? Danger does sharpen attention.