Except run on a decent system at a good speed! MacOS might have lots of nifty features, but it is by no means a technically sound system. They use the Mach microkernel (which even the HURD guys are trying to get away from and move to L4) and FreeBSD as a monolithic server (ironically, they junk the FreeBSD VM, which is probably its strongest asset, in favor of the inferior Mach one!). Thus they get the speed hit of a microkernel along with the stability problems of a monolithic kernel (if the monolithic server dies, you're system's hosed). The graphics system is stuck in the 1990's. Display PDF might be cool, but the future is hardware accelerated OpenGL imaging. (E17 has it, except others to follow. Rasterman is a visionary, admit it!) Aside from the nifty XML config stuff, and the Objective-C based API, there is really nothing on MacOS-X that isn't done better elsewhere.
You're using WINDOWS as an example of an OS where drivers just work? Seriously? Linux is pretty bad WRT drivers (many times you have to recompile because they are so dependant on kernel version, and you have to deal with modprobe and friends), but Windows is the king of "stupid reasons why the driver should work, but doesn't." There are mysterious workarounds like installing the driver three times, that shouldn't work, but does.
PS> Linus has apparently decided that Linux DOES have problems with drivers and is taking steps to rectify this. Future Linux versions should be able to load drivers transparently, with no user intervention.
So, exactly why does HURD exist? What does it bring to the table that hasn't been seen dozens of times before? (Besides allowing non-root users to mount partitions!)
Umm, that's what competition is all about. If you want GNOME to succeed, go in, help the developers, and make it suck less than KDE.
PS> No offense to the GNOME devels, of course, but currently KDE 2.2.1 is significantly more advanced than GNOME 1.4. Only you can make that different in 2.0.
You're preaching to the choir. I'm posting this from Mandrake 8.1 (which DOES, by default renice X to -1) with the preempt patches on an XFS kernel. Trust me, its still slower than Windows (at least KDE 2.2.1 and GNOME 1.4 are).
I never said ANYTHING about register specs, only OSS drivers. As a long-time BeOS user (Be couldn't pry the specs out of NVIDIA, even under NDA), I am with you in agreeing that NVIDIA should release register specs for their cards.
Why not use XFS. Sure its doesn't have holy penguin pee all over it, but I haven't heard about any stability problems with it, and its support for pro level servers (even on Linux) seems to be quite good.
In linux there are two caching mechanisms. The first one, called the buffer cache, caches physical disk blocks. For example, there might be a buffer that caches blocks 8-16 on a particular disk. The second one, called the page cache, is much newer and caches files. So the page cache would cache, for example, the first page of a file. The difference between the two is that the page cache is much higher level, and thus much more flexible. For example, blocks on a disk are 512 bytes in size. Pages are 4KB in size. Thus the first page of a file might be contained in 4 different blocks on different parts of the disk. The page cache doesn't have to care about that, since its up to the filesystem to map pages to blocks. The page cache also interfaces very nicely with memory mapped files. Normally what happens when a process writes to a memory mapped file is that the kernel allocates a page of memory, and allows the process to write to that page. Eventually, the kernel writes out that page of memory to the disk file. With the buffer cache, there is no connection between what the process sees (pages) and what the disk deals with (blocks). Thus, the kernel has to manually make sure that the buffer cache and the memory mappings are in sync with each other. If a process read()'s from a file that another process is writing to with memory mapping, the kernel has to make sure that any changes to the buffers (read()/write()) agree with changes in the pages (memory mapping). The page cache, on the other hand, deals only with pages. So what happens with the page cache is that when a process writes to a memory mapping, it points the process to the page that is caching that part of the file. When another process uses regular read() to read that file, the kernel simply copies that data from the caching page. Another benifet is that it lets stuff like NFS (in which the kernel never deals with a disk, just files) use the same caching mechanism as regular files. The last benifet is that you don't have to treat file caches any differently from regular memory. The Linux VM system automatically swaps out pages that haven't been touched in awhile. With the page cache, the VM doesn't have to deal at all with buffers. It simply has to care about how often a particular page of memory has been written to (either by memory mapping, or read/write system calls). The original cache in the Linux kernel has the buffer cache. After the page cache was added, things like NFS were immediately built to use it. Older parts, like ext2, continued to use the older buffer cache. Over time, there has been a trend to converting the kernel to using the page cache more often. In Linux 2.2, for example, ext2 used the page cache to do file reads, and only dealt with the buffer-cache for writes. In 2.4, more of the filesystem layer switched to using the page cache for writes as well.
Dude, since when does NVIDIA treat OSS with contempt? There are two reasons why the NVIDIA driver is closed source:
1) Intellectual property. NVIDIA doesn't own everything in the driver, and thus can't open it.
2) Competition. ATI's OpenGL drivers suck ass (they really hold the new 8500 card back). Don't you think they'd just love to get their hands on NVIDIA's code? NVIDIA has invested a lot of time and money into making solid OpenGL drivers, why should they just let ATI have it for free? Remember, and OpenGL driver isn't like an ethernet driver. An ethernet driver just interfaces the kernel network layer to the hardware. An OpenGL ICD, on the other hand, provides the entire OpenGL subsystem, from user-level API down to banging registers on the hardware. Its like the NIC driver AND the entire kernel network stack.
From what I've heard, yes it is 'C' compatible. Of course, you can't compile a lot of system libs with it anyway, because glibc, for example, uses GCC extensions. Generic stuff like math libs should be doable, but aren't very widely used in a system. X (since it is good about different compilers) would be the really interesting test case, maybe I'll try this weekend.
No, it uses the standard GNU linker. It exports a standard ELF program that ld.so links at runtime. However, you couldn't really use it with KDE anyway. Intel C++ has a different C++ ABI than G++ (the C ABI is of course the same) and thus can't link with G++ compiled libraries. Lastly, KDE doesn't even compile with icc yet. Look at this thread on kde-devel.
Because Linux is a real project and not some theoretical programming plaything. Kernels have all sorts of weird problems to deal with (passing parameters via registers, inline ASM, structure packing, alignment, etc) that normal application code doesn't have to bother with.
Its really not that bad. Its free for non-commercial use, and $500 isn't much for a development tool in a pro shop. Perforce licenses, for example, cost $600 per developer. There is this guy who writes programming tips-type articles (look around on/., sorry I don't remember the name). He makes the very good point that good developer tools are a drop in the bucket for the return they give in productivity.
Re:KDE is the environment of choice
on
KDE Wins 3 awards
·
· Score: 2
is typing "cd , tar -xvf "
really such an effort?
>>>>>>>>>>>>&g t;
No, but
rm -rf etc/X11/applnk/Internet/sylpheed.desktop
rm -rf/usr/bin/sylpheed
rm -rf/usr/share/doc/sylpheed-0.6.5
rm -rf/usr/share/doc/sylpheed-0.6.5/ABOUT-NLS
rm -rf/usr/share/doc/sylpheed-0.6.5/COPYING
rm -rf/usr/share/doc/sylpheed-0.6.5/ChangeLog
rm -rf/usr/share/doc/sylpheed-0.6.5/ChangeLog.jp
rm -rf/usr/share/doc/sylpheed-0.6.5/INSTALL
rm -rf/usr/share/doc/sylpheed-0.6.5/INSTALL.jp
rm -rf/usr/share/doc/sylpheed-0.6.5/README
rm -rf/usr/share/doc/sylpheed-0.6.5/README.jp
rm -rf/usr/share/doc/sylpheed-0.6.5/TODO.jp
...
is more work that
urpme sylpheed
Actually, I have found that the opposite is usually true. As wrong as you're not running GNOME session (which slows GNOME applications immensely) GTK+ apps are very responsive. ROX-Filer, for example, comes close to Windows Explorer. Balsa is much smoother than KMail, especially when it comes to resizing (almost all KDE apps rubber-band, few GTK+ apps aside from Galeon do so). Anjuta performs better than KDevelop, etc, etc. Sadly, though, Windows beats all of them. Even on my lowly 300MHz PII, I can resize IE quickly without bad rubberbanding. Konqi rubber-bands like hell, and Galeon acts like its possessed by the devil.
Actually, I have enough RAM, and KDE-2 is MUCH, MUCH, slower than 1.1.2. The stupid linker issues are part of it, but the apps don't seem to be written for performance either. (On a tangent, I think all those desktop environment coders should be forced to memorize the ROX source before touching the keyboard!) Although, you're analogy is wrong. Win2K is to Win9x as KDE 2.2.1 is to KDE 1.1.2 is a better comparison. In that case, you're analogy is wrong since Win2K is significantly faster than Win9x, even though it has tons more features. Hell, XP is faster than 2K (if you turn off Luna), especially for app-start up times (which are going in the opposite direction from those in KDE!)
Umm, BeOS had taskbar grouping long before either KDE or XP. And I don't think it was an original idea even then! Plus, I turn it off whenever possible. It is absolutely horrible to have to click twice to get that por... I mean to get to the window you want.
Since when? Compare Mozilla to IE, and you find that IE wins on both speed AND stability. And if you're talking about desktop OSs in general, Windows 2000's GUI is not only faster than any Linux GUI (except maybe Blackbox, but Win 3.1 is faster than Win2K as well!) but for the a workstation user (who reboots every week or so for some reason or another) its just as stable too.
Here's a suggestion for you: stop buying hardware that has weird stains on it. Seriously. My machine is all standard (and cheap!) hardware. SBLive!, GeForce2MX, Intel motherboard, etc. Every version of Windows since NT-4 has been rock solid on my machine. Its also a user thing. You have to baby Windows machines a little more, and get used to taking care of them. When I first started on Linux, I could crash it quite regularly, because I was using it wrong. Once you figure out how to use 2K correctly, you shouldn't have any problems.
2) A belief that C++ cannot be as fast as C. There is a little bit of overhead in C++, somewhat blown out of proportion by anti-C++ people, and therefore people think C++ is inefficient. Not really enough of a performance problem to justify this, but it is an explanation.
>>>>>>
That's not even remotely true these days. In fact, the opposite is probably true. On Windows (which makes up 90% of the desktop computing world, like it or not) C++ has been in use so long that compiler writers have been optimizing it for a long time. Straight C semantics probably get a lot less attention these days than do C++ OO semantics. As such, C++ is probably faster for day to day code. Also, there are cool things one can do with templates (such as static optimizations and generalized container classes that don't need to deference type-specific pointers) that you can't do easily in C.
Slashdot Mirror
This article explains the issue pretty well.
Except run on a decent system at a good speed! MacOS might have lots of nifty features, but it is by no means a technically sound system. They use the Mach microkernel (which even the HURD guys are trying to get away from and move to L4) and FreeBSD as a monolithic server (ironically, they junk the FreeBSD VM, which is probably its strongest asset, in favor of the inferior Mach one!). Thus they get the speed hit of a microkernel along with the stability problems of a monolithic kernel (if the monolithic server dies, you're system's hosed). The graphics system is stuck in the 1990's. Display PDF might be cool, but the future is hardware accelerated OpenGL imaging. (E17 has it, except others to follow. Rasterman is a visionary, admit it!) Aside from the nifty XML config stuff, and the Objective-C based API, there is really nothing on MacOS-X that isn't done better elsewhere.
You're using WINDOWS as an example of an OS where drivers just work? Seriously? Linux is pretty bad WRT drivers (many times you have to recompile because they are so dependant on kernel version, and you have to deal with modprobe and friends), but Windows is the king of "stupid reasons why the driver should work, but doesn't." There are mysterious workarounds like installing the driver three times, that shouldn't work, but does.
PS> Linus has apparently decided that Linux DOES have problems with drivers and is taking steps to rectify this. Future Linux versions should be able to load drivers transparently, with no user intervention.
This isn't a troll, I'm just trying to get a handle on why exactly the HURD exists.
1) Is it because its all GPL?
2) Is it because its a microkernel?
3) Maybe a new, improved microkernel? Not MACH.
4) Security?
5) Performance? Yea right.
6) Ease of use? Isn't that up to KDE and GNOME?
7) Translators, Namespace unification, RPC? Been there, done that.
So, exactly why does HURD exist? What does it bring to the table that hasn't been seen dozens of times before? (Besides allowing non-root users to mount partitions!)
Umm, that's what competition is all about. If you want GNOME to succeed, go in, help the developers, and make it suck less than KDE.
PS> No offense to the GNOME devels, of course, but currently KDE 2.2.1 is significantly more advanced than GNOME 1.4. Only you can make that different in 2.0.
You're preaching to the choir. I'm posting this from Mandrake 8.1 (which DOES, by default renice X to -1) with the preempt patches on an XFS kernel. Trust me, its still slower than Windows (at least KDE 2.2.1 and GNOME 1.4 are).
Since when does the GPL not allow restrictions on distributing binaries? It only requires the ability to get the source for free.
I never said ANYTHING about register specs, only OSS drivers. As a long-time BeOS user (Be couldn't pry the specs out of NVIDIA, even under NDA), I am with you in agreeing that NVIDIA should release register specs for their cards.
Why not use XFS. Sure its doesn't have holy penguin pee all over it, but I haven't heard about any stability problems with it, and its support for pro level servers (even on Linux) seems to be quite good.
I think you generally want to keep your filesystems about 50-60% full anyway, because ALL filesystems degrade with fragmentation and disk is cheap.
In linux there are two caching mechanisms. The first one, called the buffer cache, caches physical disk blocks. For example, there might be a buffer that caches blocks 8-16 on a particular disk. The second one, called the page cache, is much newer and caches files. So the page cache would cache, for example, the first page of a file. The difference between the two is that the page cache is much higher level, and thus much more flexible. For example, blocks on a disk are 512 bytes in size. Pages are 4KB in size. Thus the first page of a file might be contained in 4 different blocks on different parts of the disk. The page cache doesn't have to care about that, since its up to the filesystem to map pages to blocks. The page cache also interfaces very nicely with memory mapped files. Normally what happens when a process writes to a memory mapped file is that the kernel allocates a page of memory, and allows the process to write to that page. Eventually, the kernel writes out that page of memory to the disk file. With the buffer cache, there is no connection between what the process sees (pages) and what the disk deals with (blocks). Thus, the kernel has to manually make sure that the buffer cache and the memory mappings are in sync with each other. If a process read()'s from a file that another process is writing to with memory mapping, the kernel has to make sure that any changes to the buffers (read()/write()) agree with changes in the pages (memory mapping). The page cache, on the other hand, deals only with pages. So what happens with the page cache is that when a process writes to a memory mapping, it points the process to the page that is caching that part of the file. When another process uses regular read() to read that file, the kernel simply copies that data from the caching page. Another benifet is that it lets stuff like NFS (in which the kernel never deals with a disk, just files) use the same caching mechanism as regular files. The last benifet is that you don't have to treat file caches any differently from regular memory. The Linux VM system automatically swaps out pages that haven't been touched in awhile. With the page cache, the VM doesn't have to deal at all with buffers. It simply has to care about how often a particular page of memory has been written to (either by memory mapping, or read/write system calls). The original cache in the Linux kernel has the buffer cache. After the page cache was added, things like NFS were immediately built to use it. Older parts, like ext2, continued to use the older buffer cache. Over time, there has been a trend to converting the kernel to using the page cache more often. In Linux 2.2, for example, ext2 used the page cache to do file reads, and only dealt with the buffer-cache for writes. In 2.4, more of the filesystem layer switched to using the page cache for writes as well.
Dude, since when does NVIDIA treat OSS with contempt? There are two reasons why the NVIDIA driver is closed source:
1) Intellectual property. NVIDIA doesn't own everything in the driver, and thus can't open it.
2) Competition. ATI's OpenGL drivers suck ass (they really hold the new 8500 card back). Don't you think they'd just love to get their hands on NVIDIA's code? NVIDIA has invested a lot of time and money into making solid OpenGL drivers, why should they just let ATI have it for free? Remember, and OpenGL driver isn't like an ethernet driver. An ethernet driver just interfaces the kernel network layer to the hardware. An OpenGL ICD, on the other hand, provides the entire OpenGL subsystem, from user-level API down to banging registers on the hardware. Its like the NIC driver AND the entire kernel network stack.
From what I've heard, yes it is 'C' compatible. Of course, you can't compile a lot of system libs with it anyway, because glibc, for example, uses GCC extensions. Generic stuff like math libs should be doable, but aren't very widely used in a system. X (since it is good about different compilers) would be the really interesting test case, maybe I'll try this weekend.
No, it uses the standard GNU linker. It exports a standard ELF program that ld.so links at runtime. However, you couldn't really use it with KDE anyway. Intel C++ has a different C++ ABI than G++ (the C ABI is of course the same) and thus can't link with G++ compiled libraries. Lastly, KDE doesn't even compile with icc yet. Look at this thread on kde-devel.
Because Linux is a real project and not some theoretical programming plaything. Kernels have all sorts of weird problems to deal with (passing parameters via registers, inline ASM, structure packing, alignment, etc) that normal application code doesn't have to bother with.
Umm, you don't even have to do that. You can download it from Intel.
Its really not that bad. Its free for non-commercial use, and $500 isn't much for a development tool in a pro shop. Perforce licenses, for example, cost $600 per developer. There is this guy who writes programming tips-type articles (look around on /., sorry I don't remember the name). He makes the very good point that good developer tools are a drop in the bucket for the return they give in productivity.
is typing "cd , tar -xvf "
/usr/bin/sylpheed
/usr/share/doc/sylpheed-0.6.5
/usr/share/doc/sylpheed-0.6.5/ABOUT-NLS
/usr/share/doc/sylpheed-0.6.5/COPYING
/usr/share/doc/sylpheed-0.6.5/ChangeLog
/usr/share/doc/sylpheed-0.6.5/ChangeLog.jp
/usr/share/doc/sylpheed-0.6.5/INSTALL
/usr/share/doc/sylpheed-0.6.5/INSTALL.jp
/usr/share/doc/sylpheed-0.6.5/README
/usr/share/doc/sylpheed-0.6.5/README.jp
/usr/share/doc/sylpheed-0.6.5/TODO.jp
really such an effort?
>>>>>>>>>>>>&g t;
No, but
rm -rf etc/X11/applnk/Internet/sylpheed.desktop
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
rm -rf
...
is more work that
urpme sylpheed
Actually, I have found that the opposite is usually true. As wrong as you're not running GNOME session (which slows GNOME applications immensely) GTK+ apps are very responsive. ROX-Filer, for example, comes close to Windows Explorer. Balsa is much smoother than KMail, especially when it comes to resizing (almost all KDE apps rubber-band, few GTK+ apps aside from Galeon do so). Anjuta performs better than KDevelop, etc, etc. Sadly, though, Windows beats all of them. Even on my lowly 300MHz PII, I can resize IE quickly without bad rubberbanding. Konqi rubber-bands like hell, and Galeon acts like its possessed by the devil.
Actually, I have enough RAM, and KDE-2 is MUCH, MUCH, slower than 1.1.2. The stupid linker issues are part of it, but the apps don't seem to be written for performance either. (On a tangent, I think all those desktop environment coders should be forced to memorize the ROX source before touching the keyboard!) Although, you're analogy is wrong. Win2K is to Win9x as KDE 2.2.1 is to KDE 1.1.2 is a better comparison. In that case, you're analogy is wrong since Win2K is significantly faster than Win9x, even though it has tons more features. Hell, XP is faster than 2K (if you turn off Luna), especially for app-start up times (which are going in the opposite direction from those in KDE!)
Umm, BeOS had taskbar grouping long before either KDE or XP. And I don't think it was an original idea even then! Plus, I turn it off whenever possible. It is absolutely horrible to have to click twice to get that por... I mean to get to the window you want.
Since when? Compare Mozilla to IE, and you find that IE wins on both speed AND stability. And if you're talking about desktop OSs in general, Windows 2000's GUI is not only faster than any Linux GUI (except maybe Blackbox, but Win 3.1 is faster than Win2K as well!) but for the a workstation user (who reboots every week or so for some reason or another) its just as stable too.
Here's a suggestion for you: stop buying hardware that has weird stains on it. Seriously. My machine is all standard (and cheap!) hardware. SBLive!, GeForce2MX, Intel motherboard, etc. Every version of Windows since NT-4 has been rock solid on my machine. Its also a user thing. You have to baby Windows machines a little more, and get used to taking care of them. When I first started on Linux, I could crash it quite regularly, because I was using it wrong. Once you figure out how to use 2K correctly, you shouldn't have any problems.
2) A belief that C++ cannot be as fast as C. There is a little bit of overhead in C++, somewhat blown out of proportion by anti-C++ people, and therefore people think C++ is inefficient. Not really enough of a performance problem to justify this, but it is an explanation.
>>>>>>
That's not even remotely true these days. In fact, the opposite is probably true. On Windows (which makes up 90% of the desktop computing world, like it or not) C++ has been in use so long that compiler writers have been optimizing it for a long time. Straight C semantics probably get a lot less attention these days than do C++ OO semantics. As such, C++ is probably faster for day to day code. Also, there are cool things one can do with templates (such as static optimizations and generalized container classes that don't need to deference type-specific pointers) that you can't do easily in C.
bloat, but it's reusable bloat
>>>>>>>
Dude, that phrase is an instant classic! Somebody mod this guy up!