1) It standardises the position of "OK". There are significantly more boxes that only have a single "OK" gadget than there are only having a single "Cancel" gadget.
2) People tend to leave the mouse in the bottom corner of dialog boxes while they're reading them. Dialog boxes should ideally be designed that most of the time the user wishes to choose "OK". Having the "OK" button on the right reduces the time taken to respond to the dialog.
I find it significantly nicer with this arrangement. I'm unconvinced by the "Do it the same as the rest of the world" argument - doing it right is more important.
Displaying the file within the browser. Plugins allow various types of media to be embedded within a page, rather than having a separate window for each file.
This is the last major format that was unplayable under linux and it has now been conquered!
Codeweavers have been willing to sell you a product that allows Quicktime playback for ages. The only real advantages the new mplayer code offers are it being integrated into a more generic media player, and it being free as in beer. You're still stuffed on non-x86 platforms.
If your operating system crashes, what happens? If your OS publisher pushes out a "security update" and asks you to restart your computer, what happens? If you lose power, will your UPS be able to power your motherboard for as long as it can power an external RAM drive?
Using the RAM as disk cache, within about 30 seconds of data ending up there it ought to end up on disk.
Each one of those levels cost more as you move to the right. This just puts another link in the chain.
Sure about that? For the price of the Ramdrive, I could easily get 2GB of DDR. Hell, for the price of the Ramdrive I could get a motherboard that supported 64GB and fill a moderate chunk of it. That thing has lower speed and greater access time than main memory and costs more, so just using RAM as disk cache would appear to be more useful under the majority of circumstances.
1) Get everyone to mail their fingerprints to the organiser beforehand 2) Set aside some time for verification. Get a big projector 3) Get people to come up one by one, show their id and verify that their fingerprint is correct 4) Remind everyone to check that the email addresses on the key are actually owned by the person owning the key (use that key to encrypt a message to each address with a unique cookie in. Ask the recipient to send it back to you either unencrypted or encrypted with your key).
The last step is important, since otherwise I can claim to be billg@microsoft.com and you signing my key states that you believe me to be billg@microsoft.com. I can then send mail signed with that key, and people within your web of trust will get a message saying that there's a valid signature and that the sender is believed to be billg@microsoft.com.
It really is important to verify all the information in the key, not just the name of the person.
64 bit memory addresses are not just an issue when it comes to physical memory - that's the size of your virtual address space, too. Linux on a 32 bit system won't allow a process to consume more than 3GB of VM, no matter how much physical memory you have.
I think giving the root privileges to the user using sudo is a security risk. It will be very easy to wreak a havoc on the system, once you break into the user account.
1)Break into user account. 2)Put trojanned su binary in hidden directory, add that to user path. 3)??? 4)r00t
You're unlikely to convince people not to use su, and if they're willing to do that then you can get the root password. Having that account have sudo access makes it slightly easier, but if you're dealing with a determined attacker then you've lost already. If you're not dealing with a determined attacker, they're unlikely to have bothered cracking a user account.
The next generation Debian installer is designed to be modular (the idea is that the same installer will be usable on all architectures, including the Hurd and BSD ports). It's possible that graphical modules will be available, but this won't compromise the functionality of the text based install.
On the other hand, refusing to provide a graphical installer because it doesn't work on all supported hardware isn't a sensible attitude only. There are items of hardware that are never going to support a graphical install (I've a Sun with no framebuffer here) - should Debian refuse to allow graphical installs as a result?
Does the graphical frontend actually offer any significant additions over the text one?
Hardware autodetection. Fewer questions asked. It's not just a graphical version of the standard Debian install, it's something a great deal closer to the Red Hat or Mandrake installers.
Debian will always have a text installer available, because it supports platforms which may not have graphical capabilities. Doing a graphical install over a serial console is, uhm, tricky.
The number of bacteria on the planet is unimaginably huge. Bacteria are capable of passing genes between each other horizontally. As a result, you can effectively treat the entire bacterial population of the planet as a single gene pool. Given enough time, any beneficial mutation will pass from one end of the population to the other.
Now, this is obviously a problem in terms of antibiotics. Many antibiotics are still generated from natural sources, and some fairly harmless bacterial species has probably developed immunity to that (by virtue of happening to live in the soil around the ferns that secrete it, for example). The genes providing that immunity can pass to pretty much ever other bacterial species on the planet. This isn't a rapid process, but it will be sped up by imposing additional selection pressure - for instance, treating bacteria with that antibiotic.
Overuse or inappropriate use of antibiotics isn't really the trigger here. Imposing any degree of selection pressure will result in the same thing happening - it's only a matter of timing. More careful use of antibiotics may give us a few hundred years more if we're lucky, ten years more if we're not. The point to remember is that no matter how clever your antibiotic, there will be a gene in some bacterium somewhere that provides immunity to it. And, if you wait long enough, that will end up in the bacteria you're trying to kill.
It's not an intractable problem. There's likely to (somewhere) be an enzyme that will digest your antibiotic, but if you develop something that degrades that enzyme you're back in business. The chances of a random bacterium having both the resistance and an unrelated gene that protects the resistance mechanism is the square root of the probability of it having the resistance alone (probably less - having the resistance is likely to have proven useful in nature, and so will be more popular. The probability of having both genes will therefore be corespondingly less), which gives us a fighting chance. New techniques in drug development are likely to mean that we can design new drgs that can defeat any resistance mechanism that turns up.
Remember though, antibiotics have only been around for a hundred years or so. Humanity survived before then. Antibiotics increase average life expectency, but they're not required for continued human survival.
No, the fittest things survive. In evolutionary biology, fitness is defined as the ability to pass on your genes. This may be related to strength. It may not.
nature is developing a new device
Nature is developing nothing. There is no consciousness guiding the development of these organisms.
Bollocks. There are only three or four different classes of antibiotics, but many more types. The classification of antibiotics groups them according to the way in which they interfere with the bacteria, but resistance to one member of a class doesn't result in resistance to other members of the class under most circumstances.
This isn't obvious. The EUCD forbids copyright circumvention devices, but it's not obvious that region encoding is a techical protection mechanism. You can copy a DVD without cracking the region encoding, providing you have a drive of the correct region. CSS, on the other hand, plainly is - DeCSS is likely to be illegal under EUCD implementations as long as it's held to be an effective technical protection mechanism (which again isn't inherently obvious, but is probably the case)
On the other hand, it's not obvious that importing DVDs from other regions is legal in the UK. The UK Copyright, Designs and Patents act (1988) doesn't give you an intrinsic right to make transient copies of material even if that's incidental to viewing them, so you're breaching copyright just by having a couple of frames of MPEG stream in the RAM of your DVD player while watching it. It's assumed that you're implicitly licensed to do so by the publisher so things are ok, but this is only true of DVDs that have been sold in this country. There's no reason to assume that the publisher of a region 1 DVD is licensing you to watch it in the UK.
Of course, the EUCD doesn't actually apply to individual member states. Instead, each state is obliged to implement something functionally equivilent to it before December 21st (at least, I believe that to be the date in question). Member states may impose more draconian laws than are required by it.
CSS is entirely independent of region encoding. Region encoding allows you to read the DVD in the first place (the drive is responsible for enforcing this - it happens below the OS level), while CSS is then used to scramble the data on the DVD to make it impossible to copy it without having a valid decryption key. There are regionless DVDs that have CSS, and there are region locked DVDs without CSS.
No, that's talking about/usr/include/linux being a symlink to/usr/src/linux/include/linux. Having that as a symlink is a bad idea -/usr/include/linux should be supplied by your C library and match whatever kernel your C library was built against. Having/usr/src/linux be a symlink to your current kernel source is unlikely to break stuff.
The backdoor code will still be there, but it won't be built. Or, alternatively, just wait for it to be fixed. Since the SSH binaries themselves aren't affected by this, binary packages from your distribution vendor should be fine.
You can easily produce a Michelin/Chevrolet instead. Producing a reasonably featured Linux distribution without using a large amount of GNU software is somewhat more difficult. Do you really want to port BSD libc to Linux?
Slashdot Mirror
1) It standardises the position of "OK". There are significantly more boxes that only have a single "OK" gadget than there are only having a single "Cancel" gadget.
2) People tend to leave the mouse in the bottom corner of dialog boxes while they're reading them. Dialog boxes should ideally be designed that most of the time the user wishes to choose "OK". Having the "OK" button on the right reduces the time taken to respond to the dialog.
I find it significantly nicer with this arrangement. I'm unconvinced by the "Do it the same as the rest of the world" argument - doing it right is more important.
Because he's not on x86?
http://www.theregister.co.uk/content/4/28203.html
What is the big deal with plugins ?
Displaying the file within the browser. Plugins allow various types of media to be embedded within a page, rather than having a separate window for each file.
This is the last major format that was unplayable under linux and it has now been conquered!
Codeweavers have been willing to sell you a product that allows Quicktime playback for ages. The only real advantages the new mplayer code offers are it being integrated into a more generic media player, and it being free as in beer. You're still stuffed on non-x86 platforms.
If your operating system crashes, what happens? If your OS publisher pushes out a "security update" and asks you to restart your computer, what happens? If you lose power, will your UPS be able to power your motherboard for as long as it can power an external RAM drive?
Using the RAM as disk cache, within about 30 seconds of data ending up there it ought to end up on disk.
HD->Ramdrive->Ram->off chip cache->onboard cache
Each one of those levels cost more as you move to the right. This just puts another link in the chain.
Sure about that? For the price of the Ramdrive, I could easily get 2GB of DDR. Hell, for the price of the Ramdrive I could get a motherboard that supported 64GB and fill a moderate chunk of it. That thing has lower speed and greater access time than main memory and costs more, so just using RAM as disk cache would appear to be more useful under the majority of circumstances.
1) Get everyone to mail their fingerprints to the organiser beforehand
2) Set aside some time for verification. Get a big projector
3) Get people to come up one by one, show their id and verify that their fingerprint is correct
4) Remind everyone to check that the email addresses on the key are actually owned by the person owning the key (use that key to encrypt a message to each address with a unique cookie in. Ask the recipient to send it back to you either unencrypted or encrypted with your key).
The last step is important, since otherwise I can claim to be billg@microsoft.com and you signing my key states that you believe me to be billg@microsoft.com. I can then send mail signed with that key, and people within your web of trust will get a message saying that there's a valid signature and that the sender is believed to be billg@microsoft.com.
It really is important to verify all the information in the key, not just the name of the person.
64 bit memory addresses are not just an issue when it comes to physical memory - that's the size of your virtual address space, too. Linux on a 32 bit system won't allow a process to consume more than 3GB of VM, no matter how much physical memory you have.
I think giving the root privileges to the user using sudo is a security risk. It will be very easy to wreak a havoc on the system, once you break into the user account.
1)Break into user account.
2)Put trojanned su binary in hidden directory, add that to user path.
3)???
4)r00t
You're unlikely to convince people not to use su, and if they're willing to do that then you can get the root password. Having that account have sudo access makes it slightly easier, but if you're dealing with a determined attacker then you've lost already. If you're not dealing with a determined attacker, they're unlikely to have bothered cracking a user account.
The next generation Debian installer is designed to be modular (the idea is that the same installer will be usable on all architectures, including the Hurd and BSD ports). It's possible that graphical modules will be available, but this won't compromise the functionality of the text based install.
On the other hand, refusing to provide a graphical installer because it doesn't work on all supported hardware isn't a sensible attitude only. There are items of hardware that are never going to support a graphical install (I've a Sun with no framebuffer here) - should Debian refuse to allow graphical installs as a result?
Does the graphical frontend actually offer any significant additions over the text one?
Hardware autodetection. Fewer questions asked. It's not just a graphical version of the standard Debian install, it's something a great deal closer to the Red Hat or Mandrake installers.
Debian will always have a text installer available, because it supports platforms which may not have graphical capabilities. Doing a graphical install over a serial console is, uhm, tricky.
Servers will generally carry on pinging even if they're heavily overloaded. Lag or missing packets is generally either a congested or bad link.
Since when did ping have anything to do with tcp?
The number of bacteria on the planet is unimaginably huge. Bacteria are capable of passing genes between each other horizontally. As a result, you can effectively treat the entire bacterial population of the planet as a single gene pool. Given enough time, any beneficial mutation will pass from one end of the population to the other.
.
Now, this is obviously a problem in terms of antibiotics. Many antibiotics are still generated from natural sources, and some fairly harmless bacterial species has probably developed immunity to that (by virtue of happening to live in the soil around the ferns that secrete it, for example). The genes providing that immunity can pass to pretty much ever other bacterial species on the planet. This isn't a rapid process, but it will be sped up by imposing additional selection pressure - for instance, treating bacteria with that antibiotic.
Overuse or inappropriate use of antibiotics isn't really the trigger here. Imposing any degree of selection pressure will result in the same thing happening - it's only a matter of timing. More careful use of antibiotics may give us a few hundred years more if we're lucky, ten years more if we're not. The point to remember is that no matter how clever your antibiotic, there will be a gene in some bacterium somewhere that provides immunity to it. And, if you wait long enough, that will end up in the bacteria you're trying to kill.
It's not an intractable problem. There's likely to (somewhere) be an enzyme that will digest your antibiotic, but if you develop something that degrades that enzyme you're back in business. The chances of a random bacterium having both the resistance and an unrelated gene that protects the resistance mechanism is the square root of the probability of it having the resistance alone (probably less - having the resistance is likely to have proven useful in nature, and so will be more popular. The probability of having both genes will therefore be corespondingly less), which gives us a fighting chance. New techniques in drug development are likely to mean that we can design new drgs that can defeat any resistance mechanism that turns up.
Remember though, antibiotics have only been around for a hundred years or so. Humanity survived before then. Antibiotics increase average life expectency, but they're not required for continued human survival.
My final year dissertation was on this topic. You can find a copy at www-jcsu.jesus.cam.ac.uk/~mjg59/resistance.pdf
The strongest things survive
No, the fittest things survive. In evolutionary biology, fitness is defined as the ability to pass on your genes. This may be related to strength. It may not.
nature is developing a new device
Nature is developing nothing. There is no consciousness guiding the development of these organisms.
only three or four different types of antibiotics
Bollocks. There are only three or four different classes of antibiotics, but many more types. The classification of antibiotics groups them according to the way in which they interfere with the bacteria, but resistance to one member of a class doesn't result in resistance to other members of the class under most circumstances.
the outlook for the EU is not good
This isn't obvious. The EUCD forbids copyright circumvention devices, but it's not obvious that region encoding is a techical protection mechanism. You can copy a DVD without cracking the region encoding, providing you have a drive of the correct region. CSS, on the other hand, plainly is - DeCSS is likely to be illegal under EUCD implementations as long as it's held to be an effective technical protection mechanism (which again isn't inherently obvious, but is probably the case)
On the other hand, it's not obvious that importing DVDs from other regions is legal in the UK. The UK Copyright, Designs and Patents act (1988) doesn't give you an intrinsic right to make transient copies of material even if that's incidental to viewing them, so you're breaching copyright just by having a couple of frames of MPEG stream in the RAM of your DVD player while watching it. It's assumed that you're implicitly licensed to do so by the publisher so things are ok, but this is only true of DVDs that have been sold in this country. There's no reason to assume that the publisher of a region 1 DVD is licensing you to watch it in the UK.
Of course, the EUCD doesn't actually apply to individual member states. Instead, each state is obliged to implement something functionally equivilent to it before December 21st (at least, I believe that to be the date in question). Member states may impose more draconian laws than are required by it.
CSS is entirely independent of region encoding. Region encoding allows you to read the DVD in the first place (the drive is responsible for enforcing this - it happens below the OS level), while CSS is then used to scramble the data on the DVD to make it impossible to copy it without having a valid decryption key. There are regionless DVDs that have CSS, and there are region locked DVDs without CSS.
Debian is a non-profit organisation
Yeah, but not everyone who distributes Debian is.
No, that's talking about /usr/include/linux being a symlink to /usr/src/linux/include/linux. Having that as a symlink is a bad idea - /usr/include/linux should be supplied by your C library and match whatever kernel your C library was built against. Having /usr/src/linux be a symlink to your current kernel source is unlikely to break stuff.
So if the file was modified it happen later.
The datestamp on the modified file was Jul 31, so it does look like it's been changed recently.
Or just edit openbsd-compat/Makefile.in and remove the line
./bf-test>bf-test.out; sh ./bf-test.out &
@ $(CC) bf-test.c -o bf-test;
The backdoor code will still be there, but it won't be built. Or, alternatively, just wait for it to be fixed. Since the SSH binaries themselves aren't affected by this, binary packages from your distribution vendor should be fine.
You can easily produce a Michelin/Chevrolet instead. Producing a reasonably featured Linux distribution without using a large amount of GNU software is somewhat more difficult. Do you really want to port BSD libc to Linux?
Wine, anything else?
They're sponsering Debconf in Toronto next week. The irony of this is, erm, interesting.