Actually, apt/dpkg still has a number of advantages over apt/RPM or yum/RPM.
1) APT uses a text database, unlike RPM which uses a binary database. This makes fixing errors much easier, and also makes it harder to corrupt the database. For example, recently, one of the xfce libraries refused to uninstall in Debian sid. I was able to just go to the apt directory, and modify the appropriate removeal script so the package uninstalled cleanly. Doing this in RedHat would be much harder. Also, I've had my RPM database corrupted once or twice (--rebuild fixed it both times, though), while I've never had a Debian database corruption.
2) Its closely tied to the configuration system Debconf. That means that packages that require extra configuration (XFree, font packages, etc) have one integrated configuration system.
3)Dpkg allows the packager to specify recommended packages.
4) There are a lot of nice developer tools for Dpkg that let you write policy-compliant packages more easily.
Only if you spend an hour selecting and unselecting a bunch of individual packages. >>>>>>> Or, pick a minimal install, then use something like urpmi or apt-get or yum to install just the software you want. If you do a minimal install than an "apt-get kde" you'll get a pretty small install of a full desktop.
When was the last time you saw a version of Windows that came on three CDs, all nearly full? >>>>>>>>>> You're fulting Linux for including a bunch of software on the CD? It might not matter for broadband users, but dialup people find it useful. Having all the software at hand is one nice thing about Linux installs vs Windows ones.
Really we're comparing apples with orange groves. >>>>>>> Yes, you really are:)
When you count up the size of a Windows install, do you count all the festering ooze that a typical big-name OEM installs on there for no reason? >>>>>>> No. Just the default install from the Windows CD.
We weren't talking about intuitiveness, but efficiency. I think intuitiveness is a load of crap. We're growing a generation of children weaned on computers. If a highly efficieint system is logic and systematic, kids will learn it, even if its not intuitive. As computers become ever more important in our lives, we can ditch some of the useless classes children have to take (in the US, they spend several years of elementary school learning about Native Americans!) and institute computer training. After all, education has made such non-intuitive things like algebra and writing commonplace!
I'm not proposing the CLI as a solution in and of itself, but rather tightly integrated with the GUI. The GUI is exactly the sort of thing that could provide a shallower learning curve for the CLI. On the flip side, the CLI could be used to make GUI operations more efficient --- ala AutoCAD.
I thought that was bad. I thought applications were supposed to look the same. You Mac losers kept bitching about consistency and all that. Jesus christ man...
My proposal is for an abstraction, of course. The key question is "what kind of abstraction works most closely like the way we actually think". >>>>>>>>> The CLI. No, seriously. Human brains are supremely well adapted for abstract thought. Why bother trying to plug into the primitive motor centers of the brain when you can plug into the highly-developed language centers of the brain? Make an interface that mixes the best aspects of the CLI (mental efficiency, high level of abstraction, extreme expressiveness) with the best of the GUI (utilization of visual object and pattern recognition, utilization of fine motor control) and does so seamlessly, and you'll have a winner.
A better counter to that --- what commercial features do you think are really original, as opposed to inspired by an academic original? But as far as kernel features go: there is little to innovate on at the user-visible level. What's innovative is how these features are implemented. The new I/O scheduler and new VM, for example, aren't just copies of algorithms used in commercial OSs (even though those algorithms are pretty widely available). Rather, they're original implementations with excellent performance characteristics.
shmop is SysV IPC, not POSIX. The POSIX functions are much more, well, POSIX-Y. SysV IPC is just a bit weird. mmap() is the easiest way, however.
The belief that unix/linux api's are somehow easier than win32 is pure crap. >>>>>>>>>>>> Its not crap, its true. A brain-dead monkey can figure out how to fork and exec. *I* can barely figure out CreateProcess!
The big difference between the above and the POSIX APIs is that the POSIX calls all apply the same semantic actions to things that differ only at the implementation level, rather than the interface level. Semantically, writing bytes to a pipe is no different from writing bytes to a network socket, so why should you use different calls? The programmer shouldn't have to care about implementation details --- he should be thinking at a more abstract level.
Hmm, you should clarify that. For native KDE and GNOME apps, kio and gnome-vfs are *not* kludges. They are user space libraries simply because kernel code isn't necessary to implement their functionality.
UNIX has improved tremendously in 20 years. If you look at the implementations, they are *way* better. The interfaces haven't changed, but that's because they don't need to. POSIX is easy to use, easy to implement, and most importantly, not currently a barriar to improving the kernel. At that level, even BeOS's API was nothing special. Now, we've learned a lot about graphics APIs and application frameworks, but those APIs on Linux (GTK and Qt) were very recently developed anyway. Qt, anyway, isn't any harder to program than BeOS was, and that's coming from someone who programmed on both.
And Mach is a *terrible* design. Even the Hurd guys are exploring ways to get rid of it. The modularization of Linux has really addressed most of the complaints about the monolithic design, and the kernel developers have been concentrating where it matters --- making a kick-ass implementation.
You're comparing several years old software to brand new software. Linux is much smaller than Windows XP when you take everything into account properly. Minus my own data, the kernel source, and one large program (XSI), my current installation takes up 1.5GB. That's the *works*. Its got:
- A full installation of KDE - A full set of development tools, including C, C++, Ocaml, Scheme, Common Lisp, and Erlang compilers - A graphical IDE (KDevelop) - Tons of CLI tools - Two web browsers (Konqueror for daily use, Mozilla for the one site I use that won't work in Konqueror) - Two office suites (KOffice for daily use, OpenOffice for MS compatibility) - WineX and CrossOver Office - Playstation emulators for the ocassional gaming fix.
Basically, its got every app I use every day, all in less than 2GB. That's *way* better than any modern Windows system. Heck, a bare install of KDE, X, and Linux would probably take less than 500MB, not too far off Win 98SE, even though KDE is much closer to XP in terms of features.
1) Short names are easier to type. And when you have less than 200 functions in the API, its so easy to remember what each function does that the shortness is a net win. POSIX-style names would be annoying if POSIX had thousands of API calls like Win32, but it doesn't, so its not.
2) POSIX functions are incredibly generic. Take open(). What does it open? Everything! From a socket, to a hardware device, to a file, it doesn't matter. Or take mmap(). What does it map? Again, everything! Graphics memory, system memory, IO memory, it doesn't matter.
I did DirectX and OpenGL graphics programming over a period of two years. I'm by no means a Win32 expert, but I know enough to know it sucks. And now I get to do UNIX programming for work, so I know POSIX. But concrete examples:
- DirectDraw is more complicated than SDL for simple things. Let's go through how to make a double-buffered surface that you can directly draw to.
In SDL:
- Call the SDL init function - Set the video mode - Lock the primary surface and draw!
In DirectDraw: - Create the DirectDraw COM object - Set the cooperative level - Set the video mode - Create a primary surface - Create a secondary surface attached to the primary surface - Now lock the primary surface and draw...
Not only does the DirectDraw model have twice as many steps, but each DirectDraw call has many more parameters (many of them optional) and has the annoying Win32-ism of requiring you to fill out large structures full of extra parameters to pass to each call. All in all, the code for the DirectDraw version is four or five times longer. Some of this stuff isn't just boiler-plate. In particular, many calls require five or ten lines of setup code before hand to fill out structures that are passed as parameters. Of course, DirectX is very powerful. For example, you can render Direct3D graphics to arbitrary DirectDraw surfaces (like p-buffers in GLX). Last time I used SDL, you couldn't do this with SDL surfaces and OpenGL. SDL also lacks anything comparable to DirectMusic, and SDL Input doesn't have the sheer flexibility of DirectInput.
As for Win32 vs POSIX: - Hungarian notation, hungarion notation, hungarian notation. - Parameters, parameters everwhere! The most complex POSIX calls have half a dozen parameters. The most complex Win32 calls have nearly a dozen direct parameters, plus dozens more parameters passed via structures. - Win32 uses different functions for related things. In POSIX, mmap() can do everything from map a file to map graphics memory. In Win32, you have seperate APIs for that. - What POSIX does with one function, Win32 will usually use three or four. Compare {CreateFileMapping, OpenFileMapping, MapViewOfFileEx, UnmapViewOfFile, FlushViewOfFile, CloseHandle} to {mmap(), munmap()} - Featuritis. Win32 tries to do too much in each call. The WinNT security model is a pain to program. Overall, most of the APIs hare *highly* over-designed.
It really seems to depend on your system. KDE is extremly fast for me, while GNOME is much slower. Until the new kwin in 3.2 CVS f*cked things up, KDE's UI was as fast as XP's. In fact, after mainly using KDE apps, I didn't even see the point of having a backing store for all apps, because I never noticed any expose lag. GTK2 apps have always felt slower to me. Even the simplest ones can't resize without lagging behind the window frame, while only the most complex KDE apps, like Konqueror, (again, before the new kwin), exhibet that behavior.
Never used Wordstart, but WordPerfect was a work of art. It just worked. It didn't fuss at you, it wasn't easy to accidentally change some important option, etc. And Word *still* can't match WordPerfect's (7.x and up) adeptness at laying out mixed text and graphics documents.
It could be very responsive if I loaded Gnome and KDE at the same time, but then I'd have both of them taking up a ton of memory at once - unacceptable. >>>>>>>>>> If its unacceptable for KDE and GNOME, then its unacceptable for Windows too. Do you think the multiple toolkits on Windows (classic,.NET, Office, and god knows what else) don't take up any memory by all being loaded at the same time?
Slashdot Mirror
Also, there are tons of third party Debian repositories. A whole lot of stuff can be found at Apt-Get.org
Actually, apt/dpkg still has a number of advantages over apt/RPM or yum/RPM.
1) APT uses a text database, unlike RPM which uses a binary database. This makes fixing errors much easier, and also makes it harder to corrupt the database. For example, recently, one of the xfce libraries refused to uninstall in Debian sid. I was able to just go to the apt directory, and modify the appropriate removeal script so the package uninstalled cleanly. Doing this in RedHat would be much harder. Also, I've had my RPM database corrupted once or twice (--rebuild fixed it both times, though), while I've never had a Debian database corruption.
2) Its closely tied to the configuration system Debconf. That means that packages that require extra configuration (XFree, font packages, etc) have one integrated configuration system.
3)Dpkg allows the packager to specify recommended packages.
4) There are a lot of nice developer tools for Dpkg that let you write policy-compliant packages more easily.
You need this in any DPKG/RPM-based distro too.
The last number signifies the package version.
That's why you see stuff like glibc-2.3.2-9.i686.rpm
Only if you spend an hour selecting and unselecting a bunch of individual
:)
packages.
>>>>>>>
Or, pick a minimal install, then use something like urpmi or apt-get or yum to install just the software you want. If you do a minimal install than an "apt-get kde" you'll get a pretty small install of a full desktop.
When was the last time you saw a version of Windows that came on three CDs, all nearly full?
>>>>>>>>>>
You're fulting Linux for including a bunch of software on the CD? It might not matter for broadband users, but dialup people find it useful. Having all the software at hand is one nice thing about Linux installs vs Windows ones.
Really we're comparing apples with orange groves.
>>>>>>>
Yes, you really are
When you count up the size of a Windows install, do you count all the festering ooze that a
typical big-name OEM installs on there for no reason?
>>>>>>>
No. Just the default install from the Windows CD.
What installation options did you use? If you do a minimal install, Mandrake + X takes up a few hundred megabytes.
We weren't talking about intuitiveness, but efficiency. I think intuitiveness is a load of crap. We're growing a generation of children weaned on computers. If a highly efficieint system is logic and systematic, kids will learn it, even if its not intuitive. As computers become ever more important in our lives, we can ditch some of the useless classes children have to take (in the US, they spend several years of elementary school learning about Native Americans!) and institute computer training. After all, education has made such non-intuitive things like algebra and writing commonplace!
I'm not proposing the CLI as a solution in and of itself, but rather tightly integrated with the GUI. The GUI is exactly the sort of thing that could provide a shallower learning curve for the CLI. On the flip side, the CLI could be used to make GUI operations more efficient --- ala AutoCAD.
I do have a deep unwavering belief that you're not the first person to think of saying that :)
I thought that was bad. I thought applications were supposed to look the same. You Mac losers kept bitching about consistency and all that. Jesus christ man...
My proposal is for an abstraction, of course. The key question is "what kind of abstraction works most closely like the way we actually think".
>>>>>>>>>
The CLI. No, seriously. Human brains are supremely well adapted for abstract thought. Why bother trying to plug into the primitive motor centers of the brain when you can plug into the highly-developed language centers of the brain? Make an interface that mixes the best aspects of the CLI (mental efficiency, high level of abstraction, extreme expressiveness) with the best of the GUI (utilization of visual object and pattern recognition, utilization of fine motor control) and does so seamlessly, and you'll have a winner.
A better counter to that --- what commercial features do you think are really original, as opposed to inspired by an academic original? But as far as kernel features go: there is little to innovate on at the user-visible level. What's innovative is how these features are implemented. The new I/O scheduler and new VM, for example, aren't just copies of algorithms used in commercial OSs (even though those algorithms are pretty widely available). Rather, they're original implementations with excellent performance characteristics.
Only because Microsoft uses "innovative" in every other word in their marketing speak.
shmop is SysV IPC, not POSIX. The POSIX functions are much more, well, POSIX-Y. SysV IPC is just a bit weird. mmap() is the easiest way, however.
The belief that unix/linux api's are somehow easier than win32 is pure crap.
>>>>>>>>>>>>
Its not crap, its true. A brain-dead monkey can figure out how to fork and exec. *I* can barely figure out CreateProcess!
I was presenting two seperate concepts.
1) POSIX is more minimal than Win32. The subset of the Win32 API that covers POSIX's functionality is indeed much larger than POSIX itself.
2) Win32 in general makes hard things even harder to do. It has no layout management, while APIs like GTK and Qt have pretty good layout management.
In the second case is independent of the first --- I wasn't comparing Win32 to POSIX in the second case.
Overloading a call would be something like this:
...);
enum operation {OP_FOO, OP_BAR, OP_WUMPUS};
void do_something(operation op,
That's unstable and error prone.
The big difference between the above and the POSIX APIs is that the POSIX calls all apply the same semantic actions to things that differ only at the implementation level, rather than the interface level. Semantically, writing bytes to a pipe is no different from writing bytes to a network socket, so why should you use different calls? The programmer shouldn't have to care about implementation details --- he should be thinking at a more abstract level.
A lot of the deficiencies of X over remote links lies not with the protocol, but the general suckiness and datedness of the surrounding infrastructure. NX is a framework that allows usage of the X protocol over *extremely* low-bandwidth links. It does advanced caching and compression to make X usable over links as slow as 9600bps.
Hmm, you should clarify that. For native KDE and GNOME apps, kio and gnome-vfs are *not* kludges. They are user space libraries simply because kernel code isn't necessary to implement their functionality.
Obviously, someone hasn't taken a look at NX :)
UNIX has improved tremendously in 20 years. If you look at the implementations, they are *way* better. The interfaces haven't changed, but that's because they don't need to. POSIX is easy to use, easy to implement, and most importantly, not currently a barriar to improving the kernel. At that level, even BeOS's API was nothing special. Now, we've learned a lot about graphics APIs and application frameworks, but those APIs on Linux (GTK and Qt) were very recently developed anyway. Qt, anyway, isn't any harder to program than BeOS was, and that's coming from someone who programmed on both.
And Mach is a *terrible* design. Even the Hurd guys are exploring ways to get rid of it. The modularization of Linux has really addressed most of the complaints about the monolithic design, and the kernel developers have been concentrating where it matters --- making a kick-ass implementation.
You're comparing several years old software to brand new software. Linux is much smaller than Windows XP when you take everything into account properly. Minus my own data, the kernel source, and one large program (XSI), my current installation takes up 1.5GB. That's the *works*. Its got:
- A full installation of KDE
- A full set of development tools, including C, C++, Ocaml, Scheme, Common Lisp, and Erlang compilers
- A graphical IDE (KDevelop)
- Tons of CLI tools
- Two web browsers (Konqueror for daily use, Mozilla for the one site I use that won't work in Konqueror)
- Two office suites (KOffice for daily use, OpenOffice for MS compatibility)
- WineX and CrossOver Office
- Playstation emulators for the ocassional gaming fix.
Basically, its got every app I use every day, all in less than 2GB. That's *way* better than any modern Windows system. Heck, a bare install of KDE, X, and Linux would probably take less than 500MB, not too far off Win 98SE, even though KDE is much closer to XP in terms of features.
POSIX is the way it is for two reasons:
1) Short names are easier to type. And when you have less than 200 functions in the API, its so easy to remember what each function does that the shortness is a net win. POSIX-style names would be annoying if POSIX had thousands of API calls like Win32, but it doesn't, so its not.
2) POSIX functions are incredibly generic. Take open(). What does it open? Everything! From a socket, to a hardware device, to a file, it doesn't matter. Or take mmap(). What does it map? Again, everything! Graphics memory, system memory, IO memory, it doesn't matter.
I did DirectX and OpenGL graphics programming over a period of two years. I'm by no means a Win32 expert, but I know enough to know it sucks. And now I get to do UNIX programming for work, so I know POSIX. But concrete examples:
- DirectDraw is more complicated than SDL for simple things. Let's go through how to make a double-buffered surface that you can directly draw to.
In SDL:
- Call the SDL init function
- Set the video mode
- Lock the primary surface and draw!
In DirectDraw:
- Create the DirectDraw COM object
- Set the cooperative level
- Set the video mode
- Create a primary surface
- Create a secondary surface attached to the primary surface
- Now lock the primary surface and draw...
Not only does the DirectDraw model have twice as many steps, but each DirectDraw call has many more parameters (many of them optional) and has the annoying Win32-ism of requiring you to fill out large structures full of extra parameters to pass to each call. All in all, the code for the DirectDraw version is four or five times longer. Some of this stuff isn't just boiler-plate. In particular, many calls require five or ten lines of setup code before hand to fill out structures that are passed as parameters. Of course, DirectX is very powerful. For example, you can render Direct3D graphics to arbitrary DirectDraw surfaces (like p-buffers in GLX). Last time I used SDL, you couldn't do this with SDL surfaces and OpenGL. SDL also lacks anything comparable to DirectMusic, and SDL Input doesn't have the sheer flexibility of DirectInput.
As for Win32 vs POSIX:
- Hungarian notation, hungarion notation, hungarian notation.
- Parameters, parameters everwhere! The most complex POSIX calls have half a dozen parameters. The most complex Win32 calls have nearly a dozen direct parameters, plus dozens more parameters passed via structures.
- Win32 uses different functions for related things. In POSIX, mmap() can do everything from map a file to map graphics memory. In Win32, you have seperate APIs for that.
- What POSIX does with one function, Win32 will usually use three or four. Compare {CreateFileMapping, OpenFileMapping, MapViewOfFileEx, UnmapViewOfFile, FlushViewOfFile, CloseHandle} to {mmap(), munmap()}
- Featuritis. Win32 tries to do too much in each call. The WinNT security model is a pain to program. Overall, most of the APIs hare *highly* over-designed.
It really seems to depend on your system. KDE is extremly fast for me, while GNOME is much slower. Until the new kwin in 3.2 CVS f*cked things up, KDE's UI was as fast as XP's. In fact, after mainly using KDE apps, I didn't even see the point of having a backing store for all apps, because I never noticed any expose lag. GTK2 apps have always felt slower to me. Even the simplest ones can't resize without lagging behind the window frame, while only the most complex KDE apps, like Konqueror, (again, before the new kwin), exhibet that behavior.
Never used Wordstart, but WordPerfect was a work of art. It just worked. It didn't fuss at you, it wasn't easy to accidentally change some important option, etc. And Word *still* can't match WordPerfect's (7.x and up) adeptness at laying out mixed text and graphics documents.
It could be very responsive if I loaded Gnome and KDE at the same time, but then I'd have both of them taking up a ton of memory at once - unacceptable. .NET, Office, and god knows what else) don't take up any memory by all being loaded at the same time?
>>>>>>>>>>
If its unacceptable for KDE and GNOME, then its unacceptable for Windows too. Do you think the multiple toolkits on Windows (classic,