For example, a desktop OS will have a scheduler optimised for latency while a server OS will have one optimised for throughput.
Linus Torvalds seems to disagree with that notion:
When it comes to schedulers, "performance" *is* pretty damn well-defined,
and has effectively universal meaning.
The arguments that "servers" have a different profile than "desktop" is
pure and utter garbage, and is perpetuated by people who don't know what
they are talking about. The whole notion of "server" and "desktop"
scheduling being different is nothing but crap.
I don't know who came up with it, or why people continue to feed the
insane ideas. Why do people think that servers don't care about latency?
Why do people believe that desktop doesn't have multiple processors or
through-put intensive loads? Why are people continuing this *idiotic*
scheduler discussion?
Right now, flash is by far the best way to deliver video on the web. It's got a way higher install base than any other video format
No, it hasn't. MPEG2 video works on any version of Windows since Windows 95, even those installations without Flash. It'll also work on Mac OS X, GNU/Linux, and many OSes that Adobe doesn't provide Flash for.
I've had bad experiences with HP laptops before. This was several years ago, so I may not remember everything correctly.
My HP Pavilion laptop had the USB controller on IRQ 11, but, according to 2 out of 3 BIOS tables, it was on IRQ 9. This caused USB not to work under Linux. HP and the BIOS vendor apparently weren't interested in fixing the issue, so, eventually, it was worked around with a patch to Linux. According to what I've heard, the USB controller worked under Windows, but would reset every 5 minutes.
What Pavilion model exactly, if I may ask?
I'm currently browsing for medium-end secondhand laptops, and a HP Pavilion ZE4900 is one of the interesting offers. If it's total crap, I'd prefer to know that before I buy it:)
If I'm not mistaken, mencoder, from the mplayer project, can do this. The program is quite dense in its options, and requires some getting used to, but it can do quite a lot.
And any mention of a possible solution brings down the wrath of nerds who want to keep unix as unintuitive and awkward as possible.
That's just trolling. There are many people looking for a _good_ way to do these things, and then fix them. Why do you think Freedesktop.org exists in the first place? See this for the solution.
Besides the nuisance of what mouse click or keystroke you use to move text, it's not a clipboard like Windows uses, merely a text buffer.
Ie; it's only good for text. You cant copy/paste (and by extension drag and drop) files, bitmaps, etc uniformly between apps.
No, the clipboards can hold any data type, not just text. It's the widgetsets and/or applications that cannot handle anything other than text. These should be fixed (and that's slowly moving in the right direction).
I think the reason for the two different Clipboards is because the KDE (Or gnome? Not sure if it works the same way) clipboard handles copying content other than plain text and the X-Windows one not.
Wrong. X' selections mechanism (which is a general data sharing mechanism that's also used for copy/paste) supports any kind of data, not just text. It's the widgetsets and/or applications that don't understand anything other than text. Luckily, this is improving as GTK and QT are working on this.
From the ICCCM, section 2.6.2 (referring to data transferred through selections):
The atom that a requestor supplies as the target of a ConvertSelection request determines the form of the data supplied. The set of such atoms is extensible, but a generally accepted base set of target atoms is needed. As a starting point for this, the following table contains those that have been suggested so far.
One of the really cool, yet rarely used, features of the selection mechanism is that it can negotiate what data formats to use. It's not just about text. When one application asks another for the selection, part of their communication involves the requester asking the owner for the list of types in which they are capable of delivering the selection data; then the requester picks the format they like best, and asks for it that way.
By the way, "X-Windows" doesn't exist, it's the "X Window System", or "X" for short.
Use applications that support copy/paste correctly, and file wishlist bugs against applications that don't.
X (or actually: the standards lying on top of it, such as the ICCCM and Freedesktop.org's specs), supports two concurrent copy/paste clipboards; One for select-middle-click-paste, and one for classical copy/paste using explicit actions.
This way, you can select text A, ctrl-C it, select text B, and ctrl-V-paste text A over text B, just like you're used to. Additionally, you can do a quick copy/paste by just selecting text and middle-click-pasting it (this is more of a shortcut, and can for example be ignored by non-computer-literate users).
Unfortunately, although X supports this fine, the UI widgetsets, as usual, have been lacking proper support for this. Recently, this has much improved, and at least GTK 2 and QT 3 support this correctly. What we need to do now is fixing all widgetsets and/or applications that don't do this properly.
See this paper from Freedesktop.org for a more detailed explanation.
Re:As flattering a photo of RMS as there'll ever b
on
Stallman vs Ken Brown
·
· Score: 1
Personally, I like this picture of Stallman (from this site, although that hardly seems the original source).
He has a more quiet and wise look in that picture than he does in most other pictures.
I second the HTML version. Good old Adobe - popped up a nice little window in the background bugging me to update and stalled the IE process. Since the window went to the background, all I could see was the stalled process, and I killed IE, which, of course, closed all my windows. I hate pdf files...
It seems you hate Acrobat Reader, not PDF files.
PDF is in fact a very good format, especially if you want your final document (especially if it's intended for paper) to look the same across many different computers.
So the writer spent dozens upon dozens of hours building, tearing down, rebuilding and troubleshooting something that's going to be less reliable and more expensive than a TiVo?
I know you're joking, but...
What do you learn from buying a TiVo? Nothing.
What do you learn from building, tearing down, and troubleshooting something, and repeating that process? A lot.
In the end, he may not be a lot richer physically, but he had fun building his thing (or at least, I hope so), and he's become more experienced, and wiser, which is mental richness. That may be worthless to some (whom I pity), it's priceless to others.
But the one thing that blows me away is that many of the "desktop" mobos for AMD 64 still only allow a maximum of 2 or 4GB of phyisical RAM. What the hell is the point of a 64bit architecture if you can't use more of the address space than with IA32 processors? Surely not 64bit math?
There is more than just a larger address space. 64 bit math can help, and so can the 8 extra general purpose registers that AMD added.
But even with 'only' 4 GB of RAM, a larger address space helps.
First of all, applications never get the full address space (at least, not on x86, on some archs it's different). On Windows, they get 2 GB, on GNU/Linux, they get 3 GB. On both OSses, this can be enlarged somewhat, but that incurs a performance penalty. So, for individual apps (such as heavy image or video editors), having 4 GB of RAM on x86 isn't useful.
Adding to the problem above, not only physical memory is mapped to the applications address space. Memory mapped files and paged out memory are too, for example. That means that using 8 GB of memory for a single app (4 GB RAM, 4 GB swap) is impossible on x86 but possible on x86-64.
Once again adding to the address space pressure is memory fragmentation. If, assuming a 3 GB address space, an application allocates 3 1 GB blocks, and frees the outermost two, it only uses 1 GB; this 1 GB resides in the middle of its address space, leaving 1 GB available before it, and 1 GB after it. That means the application could not allocate a 2 GB block anymore. (Apps that have such memory demands not rarely do some internal memory management, but that isn't exactly ideal)
Those are a few of the largest problems you can encounter when you're pushing the limit of your address space. Increasing the 4 GB address space has merits even before you have a system with 4 GB RAM.
There also are practical reasons for the absence of inexpensive motherboards that can handle more than 4 GB, too. 2 GB PC2700 or PC3200 DIMMs don't exist yet to my knowledge (and if they do, they're insanely expensive), so you're stuck with 1 GB DIMMs (which aren't cheap either). That means that to have more than 4 GB, you need more than 4 memory slots. And that's a problem. The high frequency signals of todays memory are sensitive to crosstalk, capacitance, timing issues and termination, especially with so many traces. For normal, unbuffered DIMMs, 4 memory slots on the same memory controller is the very maximum if you're to stay within specifications. Just adding more slots won't work.
A solution is adding more memory controllers, but that's expensive and impossible on Athlon-64's without altering the CPU. Another solution is using registered memory (which takes part of the load of the memory controller), but that's both slower and more expensive.
For more RAM, the best option is to wait until manufacturers can stuff more bits in a chip. Most other tactics are facing severe problems.
At least a full distro of Windows still fits on a single cd-rom unlike some other operating systems.
I assume you are referring to GNU/Linux and the BSDs and such.
It has already been pointed out that a typical distribution includes vast amounts of optional applications. But there is more: with most (if not all) distributions, you can go ahead and use only the first CD, for a basic OS with little frills.
So, these OSses DO fit on a single CD. The additional applications don't.
Besides, take a look at Knoppix, a Debian-based GNU/Linux bootcd. It packs loads of software, far more than a default Windows XP install, and yet it fits on a single CD-ROM. If you don't know already: it runs completely from CD-ROM and doesn't touch your harddrive.
You basically say that Apache is insecure, and you don't give any arguments for that. That is flamebait.
If you don't want to be moderated as flamebait, then back up your statements with arguments, examples, perhaps statistics or other data, more detailed opinions, etc, etc.
There are many alternative servers available whos primary goal is security. They're easier to configure, secure, and maintain.
That is slightly better, but you still aren't really saying anything. Basically you say "there are more secure alternatives", but that can easily be said of any product, mostly because is not verifiable. An example (which you refuse to give until it's hammered out of you; you refer to freshmeat.net instead) would do wonders at this point.
Besides, most people don't need all the bells and wistles Apache offers.
Finally, something that might be a real argument. Apache offers lots of functionality, and not everyone needs it. That is indeed a scenario that can lead to security risks.
But there's more to it than that, much of Apache's unneeded functionality can be disabled for example, and there are really useful things in Apache's possibilities. But I am not (nor pretend to be) a webserver guru, so I am not going into a detailed discussion about that.
Yes, this may only be an issue with "bad" C code that assumes it will ever only run on a 32-bit platform... That probably covers 99% of all x86 C code out there, for any OS you care to name.
For any OS I care to name? I daresay that a lot of software for GNU/Linux is 64-bit clean. Not all software ofcourse, but certainly more than one percent.
Don't forget that GNU/Linux and it's software is ported to and actually used on a large number of platforms. Consider Debian GNU/Linux; it's latest release (3.0 aka Woody) has 8500 packages, for a total of 11 architectures, which includes 32 and 64 bit architectures in various endiannesses too. And all the 8500 packages (give or take a few, some are platform-specific) are compiled for and tested on all those architectures.
The same goes for NetBSD, FreeBSD and OpenBSD; it's the same software that runs on it.
I read the word 'emulation' and I didn't see it specify which architecture, so one would assume its emulated.. sooo would run on i386 too
Well, I don't know how correct the term "emulation" is... The ability to run Darwin binaries does not require emulation, it just requires the NetBSD kernel to provide a Darwin ABI to its functions, just like it provides a NetBSD ABI to its functions (and like it can provide a Linux ABI). That is just about different "interfaces" for one kernel, and in that sense, Darwin binaries are not running any more emulated than NetBSD binaries.
The graphical part however might be different, and might technically be emulation, although I'm not sure.
But, anyway, total ppc emulation (to run the binaries on other platforms too) is many times slower and many times more difficult than just providing Darwin binary compatibility and a graphical compatible something.
From the article:
Once we will have a fully functionnal Darwin binary compatibility on NetBSD/powerpc (if that happens some day)
So, yes, it's for NetBSD/ppc only. If I remember correctly, complete ppc emulation was discussed too, but that will have to wait at least until the "normal" binary compatibility is functional:)
In other words, don't count on running MacOS X binaries on your PC for a while, as creating a complete CPU emulator is quite tough, especially if decent performance is a must.
Now one can run native Xapps, windows AND OSX apps on a unix box..
Actually, running Windows apps on NetBSD will prove quite hard, since Wine doesn't run on NetBSD.
Quote from the Wine FAQ:
NetBSD, OpenBSD, Unixware, and SCO OpenServer 5 worked at one time, but Wine now requires kernel-level threads which are not currently available (or understood by the Wine team) in those platforms.
Knoppix does not use zisofs. Knoppix uses a regular iso9660 filesystem (with rockridge extensions so you have perms/ownership in Unices) to house a basic system. This makes the CD readable in any OS that understands iso9660.
Most of the software however (think/usr) is stored in a filesystem in a file. This file is compressed, and then mounted via a cloop (compressed loopback) device (just like you can mount a.iso image via the loopback device, but this time with compression).
Sound nice, but this kind of tools need direct access to the hardware. Linux provides a (abstraction) shield for this.
Any program running as root (which would make sense on a BIOS-flashing floppy) can get direct access to hardware. Normally the IN and OUT ops are restricted; any program issuing them will get a SIGILL from the kernel. But a program running as root can request access to specific I/O ports with ioperm(), or it can raise its privilige level with iopl(), giving it access to all I/O ports.
This is also the way XFree86 accesses the hardware without needing to go through the kernel.
The other (somewhat prettier) way would be to write a kernel module that provides abstracted access to low-level BIOS and CMOS stuff, so any program could interact with it using e.g./dev/bios.
Slashdot Mirror
Linus Torvalds seems to disagree with that notion:
I'm currently browsing for medium-end secondhand laptops, and a HP Pavilion ZE4900 is one of the interesting offers. If it's total crap, I'd prefer to know that before I buy it
If I'm not mistaken, mencoder, from the mplayer project, can do this. The program is quite dense in its options, and requires some getting used to, but it can do quite a lot.
Thanks.
ftp://galileo.luon.net/pub/linux/debian/3.1/CD-ima ges
See this (section 2.6.2) and this for details.
From the ICCCM, section 2.6.2 (referring to data transferred through selections): From a document explaining X selections: By the way, "X-Windows" doesn't exist, it's the "X Window System", or "X" for short.
Use applications that support copy/paste correctly, and file wishlist bugs against applications that don't.
X (or actually: the standards lying on top of it, such as the ICCCM and Freedesktop.org's specs), supports two concurrent copy/paste clipboards; One for select-middle-click-paste, and one for classical copy/paste using explicit actions.
This way, you can select text A, ctrl-C it, select text B, and ctrl-V-paste text A over text B, just like you're used to. Additionally, you can do a quick copy/paste by just selecting text and middle-click-pasting it (this is more of a shortcut, and can for example be ignored by non-computer-literate users).
Unfortunately, although X supports this fine, the UI widgetsets, as usual, have been lacking proper support for this. Recently, this has much improved, and at least GTK 2 and QT 3 support this correctly. What we need to do now is fixing all widgetsets and/or applications that don't do this properly.
See this paper from Freedesktop.org for a more detailed explanation.
Personally, I like this picture of Stallman (from this site, although that hardly seems the original source).
He has a more quiet and wise look in that picture than he does in most other pictures.
PDF is in fact a very good format, especially if you want your final document (especially if it's intended for paper) to look the same across many different computers.
What do you learn from buying a TiVo? Nothing.
What do you learn from building, tearing down, and troubleshooting something, and repeating that process? A lot.
In the end, he may not be a lot richer physically, but he had fun building his thing (or at least, I hope so), and he's become more experienced, and wiser, which is mental richness. That may be worthless to some (whom I pity), it's priceless to others.
But even with 'only' 4 GB of RAM, a larger address space helps.
- First of all, applications never get the full address space (at least, not on x86, on some archs it's different). On Windows, they get 2 GB, on GNU/Linux, they get 3 GB. On both OSses, this can be enlarged somewhat, but that incurs a performance penalty. So, for individual apps (such as heavy image or video editors), having 4 GB of RAM on x86 isn't useful.
- Adding to the problem above, not only physical memory is mapped to the applications address space. Memory mapped files and paged out memory are too, for example. That means that using 8 GB of memory for a single app (4 GB RAM, 4 GB swap) is impossible on x86 but possible on x86-64.
- Once again adding to the address space pressure is memory fragmentation. If, assuming a 3 GB address space, an application allocates 3 1 GB blocks, and frees the outermost two, it only uses 1 GB; this 1 GB resides in the middle of its address space, leaving 1 GB available before it, and 1 GB after it. That means the application could not allocate a 2 GB block anymore. (Apps that have such memory demands not rarely do some internal memory management, but that isn't exactly ideal)
Those are a few of the largest problems you can encounter when you're pushing the limit of your address space. Increasing the 4 GB address space has merits even before you have a system with 4 GB RAM.There also are practical reasons for the absence of inexpensive motherboards that can handle more than 4 GB, too. 2 GB PC2700 or PC3200 DIMMs don't exist yet to my knowledge (and if they do, they're insanely expensive), so you're stuck with 1 GB DIMMs (which aren't cheap either). That means that to have more than 4 GB, you need more than 4 memory slots. And that's a problem. The high frequency signals of todays memory are sensitive to crosstalk, capacitance, timing issues and termination, especially with so many traces. For normal, unbuffered DIMMs, 4 memory slots on the same memory controller is the very maximum if you're to stay within specifications. Just adding more slots won't work.
A solution is adding more memory controllers, but that's expensive and impossible on Athlon-64's without altering the CPU. Another solution is using registered memory (which takes part of the load of the memory controller), but that's both slower and more expensive.
For more RAM, the best option is to wait until manufacturers can stuff more bits in a chip. Most other tactics are facing severe problems.
ftp://galileo.luon.net/pub/linux/ibm_ad.mpg
It has already been pointed out that a typical distribution includes vast amounts of optional applications. But there is more: with most (if not all) distributions, you can go ahead and use only the first CD, for a basic OS with little frills.
So, these OSses DO fit on a single CD. The additional applications don't.
Besides, take a look at Knoppix, a Debian-based GNU/Linux bootcd. It packs loads of software, far more than a default Windows XP install, and yet it fits on a single CD-ROM. If you don't know already: it runs completely from CD-ROM and doesn't touch your harddrive.
If you don't want to be moderated as flamebait, then back up your statements with arguments, examples, perhaps statistics or other data, more detailed opinions, etc, etc. That is slightly better, but you still aren't really saying anything. Basically you say "there are more secure alternatives", but that can easily be said of any product, mostly because is not verifiable. An example (which you refuse to give until it's hammered out of you; you refer to freshmeat.net instead) would do wonders at this point. Finally, something that might be a real argument. Apache offers lots of functionality, and not everyone needs it. That is indeed a scenario that can lead to security risks.
But there's more to it than that, much of Apache's unneeded functionality can be disabled for example, and there are really useful things in Apache's possibilities. But I am not (nor pretend to be) a webserver guru, so I am not going into a detailed discussion about that.
Don't forget that GNU/Linux and it's software is ported to and actually used on a large number of platforms. Consider Debian GNU/Linux; it's latest release (3.0 aka Woody) has 8500 packages, for a total of 11 architectures, which includes 32 and 64 bit architectures in various endiannesses too. And all the 8500 packages (give or take a few, some are platform-specific) are compiled for and tested on all those architectures.
The same goes for NetBSD, FreeBSD and OpenBSD; it's the same software that runs on it.
Debian does that. It provides a pine396-src package, which contains the source and patchfiles.
The graphical part however might be different, and might technically be emulation, although I'm not sure.
But, anyway, total ppc emulation (to run the binaries on other platforms too) is many times slower and many times more difficult than just providing Darwin binary compatibility and a graphical compatible something.
From the article: So, yes, it's for NetBSD/ppc only. If I remember correctly, complete ppc emulation was discussed too, but that will have to wait at least until the "normal" binary compatibility is functional
In other words, don't count on running MacOS X binaries on your PC for a while, as creating a complete CPU emulator is quite tough, especially if decent performance is a must.
Quote from the Wine FAQ:
Knoppix does not use zisofs. Knoppix uses a regular iso9660 filesystem (with rockridge extensions so you have perms/ownership in Unices) to house a basic system. This makes the CD readable in any OS that understands iso9660.
/usr) is stored in a filesystem in a file. This file is compressed, and then mounted via a cloop (compressed loopback) device (just like you can mount a .iso image via the loopback device, but this time with compression).
Most of the software however (think
Any program running as root (which would make sense on a BIOS-flashing floppy) can get direct access to hardware.
Normally the IN and OUT ops are restricted; any program issuing them will get a SIGILL from the kernel. But a program running as root can request access to specific I/O ports with ioperm(), or it can raise its privilige level with iopl(), giving it access to all I/O ports.
This is also the way XFree86 accesses the hardware without needing to go through the kernel.
The other (somewhat prettier) way would be to write a kernel module that provides abstracted access to low-level BIOS and CMOS stuff, so any program could interact with it using e.g.