I would rather see Comcast improve their DNS server availability first, or at least in addition. For the last three months, I've turned to using another DNS provider because Comcast sees fit to run nightly maintenance on their servers sometime after 01:30 CST. Rarely has connection to the internet been compromised, rather to the DNS servers themselves. If they're using load-balancing hardware, I'm not seeing it as an end-user. Hopefully they can piggy-back a reliable high-availability architecture in addition to DNSSEC...
4. If we disclose a bug and fix it, it just escalates the "arms race" with the hackers. Better to keep it hidden.
Exactly what Mr. Blackhat is thinking, "Keep it hidden." Chances are if the software developers know about an exploitable bug, so do the crackers. It may be that the "script-kiddies" are still in the dark, but I don't consider "script-kiddies" as being in the "arms race." Note, however, that the article didn't say the company wouldn't fix low/medium security bugs, rather they wouldn't publicize the fix when it was finally rolled out in the product.
Back in the day, oh around 1995, my college buddies and I used to play
on the Realms of Despair MUD. The Gods that be were heavily improving
the codebase and adding new classes. Our favorite class at the time
was the Vampire. It seemed to have all of the benefits of a Thief,
Mage, and Fighter class all rolled into one.
Instead of mana, vampires used blood points. Young vampires did not
have the feed skill, but could drink from a pool of blood created
under their slain victims. In any case, there was a bug with the feed
skill, probably intended as a feature. When a vampire fed, it both
replenished the blood point pool, but also the health points. It took
a while to tweak the system to the correct balance, but until then, we
had no need of healing spells or potions. Just script tinyfugue or
tintin++ to always throw in a few feeds whenever the blood points or
health points were getting low, and violla! The most effective attack
was to cast invisibility, backstab, feed, and then go into whatever
sequence of attack you might have in mind.
Our other favorite bug was to duplicate equipment. Characters and
their equipment were not always saved whenever a "transaction"
occurred. For example, if a character picked up a sword, the MUD
didn't automatically save this to the inventory. Characters were
saved periodically, though they could force it through the "save"
command.
If you could find a way to crash the MUD (exit a room out a door that
didn't exist or some such gem of secret information) you were golden.
Character A hands character B a piece of equipment, be it a weapon,
gold, or bag containing any number of items. Character B types
"save", and A or B then crashes the server. When it comes back up,
Character A and B have a copy of the equipment in their inventory.
Of course, the Gods quickly figured this out and started tacking
unique serial numbers onto pieces equipment and running periodic
audits...
Package: digitaldj Priority: optional Section: sound Installed-Size: 268 Maintainer: Tim Dijkstra (tdykstra) <tim@famdijkstra.org> Architecture: i386 Version: 0.7.3-1 Depends: maplay3 | mpg123 | amp | vorbis-tools, libc6 (>= 2.2.4-4), libgdk-pixbuf2 (>= 0.17.0-2), libghttp1 (>= 1.0.9-9), libglib1.2 (>= 1.2.0), libgtk1.2 (>= 1.2.10-4), liblircclient0, libmysqlclient10, xlibs (>> 4.1.0) Recommends: grip Suggests: mysql-server Filename: pool/main/d/digitaldj/digitaldj_0.7.3-1_i386.deb Size: 71060 MD5sum: f4660984f6081bef5a49a3dab953b49f SHA1: 3ca0d750213e9203a1cf298178481ca2f28a6c67 SHA256: cb0e7a0a08dcb49e5899fc20dcbdb10c3777080095d644c211 19408368209bb7 Description: An SQL based mp3 player front-end DigitalDJ is an SQL-based mp3/ogg-player front-end designed for people who want to create an mp3 version of their CD collection. It is designed to work with the Grip ripping/encoding application (but can be used separately). When Grip encodes mp3 or ogg files, it will place all of the song information into an SQL database. DigitalDJ can then use this information to create playlists based on a number of criteria. . You will need a MySQL server, which can either be on the local or a remote host. . Homepage: http://nostatic.org/ddj/index.shtml
I am so glad that I read/. occassionally! I was contemplating getting DISH network for our house because of the drastic price savings over the competitors. I had assumed that I could buy/build a Tivo/MythTV box and attach it to my DISH receiver. Now I learn that it isn't going to happen any time soon! Thanks/. for preventing me from making a big consumer mistake!
It's not horribly complicated to set up backups with amanda on a Mac OS X machine. I agree, it would be nice to have a precompiled, self-contained *.app, but this should suffice in the mean time.
Install Mac OS X Developer Tools (for gcc)
Install Xtar (google for it), a version of GNU tar that understands resource forks, etc.
Compile amanda, pointing to xtar as the default path for tar.
The type of interface you're thinking about is something along the lines of a text-based MUD or IRC client, where your commands are hooked BEFORE being sent to the server. I personally don't know of any, but can't imagine that it hasn't been considered. Currently, OpenSSH uses the "~" character to indicate that an SSH command will follow. "~C" drops you to an "ssh>" prompt to add things like tunneling while you're still connected to the host. Evidently, the ability to intercept input and redirect it to a local function is already built in to the software. IIRC, you can change the command character if "~" is too clunky for you.
The next task is to extend this to provide an alias function. For example, you could bind "~a" to a theoretical "run-alias ALIAS ARGS" command. The desired effect is to output the expanded or constructed shell commands to the host. You will likely want to bind an interpreter to the run-alias command rather than creating your own. Find a license that is compatible with the OpenSSH client or whatever client you might be using.
A friend of mine actually owned a PC when I was in college. He had just gotten a huge 1GB hard drive and was downloading DOOM wads like a madman when he came across the Alien wad. The damn mobs moved so friggin fast. Playing the game with all of the lights turned off, a blanket over my head and monitor, with headphones on literally had me jumping out of the seat when one of the aliens would pop out of its hiding place and rip my face off.
I'm not 100% certain, but I have a vague feeling that you really don't understand BitTorrent. You don't have to leave the client open after you've downloaded your file. You are sharing bits and pieces of the file you're downloading as you're downloading it. For more information on the actual protocol and it's design, visit here.
Just to add this to the suggested list of applications:
smartmontools
control and monitor storage systems using S.M.A.R.T.
lmbench
Utilities to benchmark UNIX systems
memtest86
Test your memory on x86 platforms
nictools-nopci
Diagnostic tools for many non-PCI ethernet cards
nictools-pci
Diagnostic tools for many PCI ethernet cards
lm-sensors
utilities to read temperature/voltage/fan sensors
mbmon
Hardware monitoring without kernel dependencies (text client)
sensord
hardware sensor information logging daemon
crashme
Stress tests operating system stability
fuzz
stress-test programs by giving them random input
spew
I/O performance measurement and load generation tool
stress
A tool to impose load on and stress test a computer system
cpuburn
a collection of programs to put heavy load on CPU
ltp
The Linux Test Project test suite
Lucas tried to remove the fantasy element by introducing a biological symbiot to "all living things in the universe". This, of course, is simply hogwash, because eventually we see that ghosts of passed Jedi are allowed to walk appear anywhere they wish. Some geekoid will try to defend ghosts as some "singular expression of a personality though the omnipresent matrix of medaclorians," which so happen to communicate over vast amounts of space instantaneously. This ties together nicely Luke's ability to feel Han's torture and Darth Vadar and the Emperor's ability to coordinate tactical command of vast starfleets.
Hey, it's sci-fi/fantasy; a space opera. If it wasn't, it would be Battle Star Galactica. Suspend disbelief and enjoy.
Of course, we're assuming that you've read http://www.bittorrent.com/guide.html, which shows you how to do it. Recent versions are trackerless,
so setting up the tracker is no longer valid, though if you want to service the 3.x versions, you may still want to set one up.
There's always freshmeat to search for options. EZTorrent appears to be what you want. mod_bt also looks promising if you're using Apache 2.x.
I think one thing people misunderstand about packages is not necessarily the format of the package itself (which is certainly important), but the robustness of the tools with which you can operate on those packages. Part of your comment is targeted in that direction, and I agree. Tools are converging in features. Improvements are being made across the board on both camps. dpkg and apt, for example, have some interesting enhancements on deck. Just check out the dpkg ChangeLog if you're looking for examples of changes already made.
Regarding format, though, I still believe DEB's win for flexibility, accessibility, and a simple, straight-forward design. Baroque is hardly the word to describe the "./debian" maintainer scripts directory. What does one find in "./debian"? control, changelog, copyright, README.Debian, rules (the build Makefile), and optionally the prerm, postrm, preinst, postinst scripts. Whatever else a maintainer puts in that directory that is useful for the build process is entirely subjective to the helper tools they might use (like debhelper).
DEB's are simply two tarballs archived together, data.tar.gz, which contains the package files themselves, and control.tar.gz, which contains the maintainer scripts. If you did not have dpkg installed on your system, but wished to extract the files and information from a DEB, you would simply use the tools ar and tar. To do the same with an RPM is to open up a hex editor to find the end of the RPM header, then use dd to cut it off and output the remaining tarball. (RPM format) How many people know or want to know how to do that?
The other flexiblity that DEB's have that RPM's don't (didn't?) is that maintainer scripts can be written in any language the maintainer wishes, as long as the interpretor is installed at the time the script runs. If you're maintaining a Perl package, it's reasonable to assume that Perl can be installed as a (pre-)dependency and used to run the maintainer scripts.
Debconf, for example, is one of those optional helper tools the maintainer is encouraged to use when questions must be asked of the user/administrator at installation time. Gone are the days when DEB's could not be installed unattended. Using Debconf allows the maintainer to provide those questions, and allows the user to view them using one of multiple interfaces, or to ignore them completely. Additionally, po-debconf makes it trivial to add multilingual support for those questions.
There is plenty of documentation, utilities, and helper tools to create a Debian package, and on-line resources such as IRC, email lists, and forums. An interesting thread to read dates back from 1996, titled "Why the.deb format?". Also, take a gander at this FAQ.
Really, comparing RPM's to DEB's is like comparing apples to oranges. RPM maintainers may baulk at the "debian/" directory and maintainer scripts, but I personally baulk at having to learn yet another spec file format for RPM's and being restricted to using librpm or a hex editor to access the data contained within the package.
I think what they really suffer from, and I am not expert, is politics of a large system and the perception of lots of power sitting on top. I could be wrong.
Actually, I do think you're wrong, but I am biased in that I'm a Debian Developer. Developers only have to get involved in "politics" if they really wish, but the bulk of developers happily work on the half-a-dozen or so packages they're maintaining and leave the "politics" to the people who care about them. I consider myself amongst this group of moderates, if you wish to pin political terminology upon us.
So really, what is political about security fixes? Nothing, and the mechanisms for updating packages do not revolve around politics either. The basic formula is:
Email security@debian.org with a description of the bug your package is afflicted with.
A patch is helpful, but remember that only the security team is allowed to upload the new, signed package.
Let the security team handle the rest.
I want you to notice a couple things about this process. The developer is equally responsible as the security team for recognizing a security bug (via watching security bulletins, etc) and for responding to bug reports against his/her package. Even if the patch isn't backported against the Stable package, the developer should notify security@debian.org that there is a problem,
And finally, note how the responsibility for uploading the new binary and source packages lies in the hands of the security team. This is where our concern lies. Is there enough people on the security team to cover 1500+ packages? Probably not. I believe that this is the reason the blog entry was made. Not to undermine or discredit Debian, but to address a shortcoming that can and will be addressed.
If you don't feel like a do-it-yourselfer, you can buy 1-wire temp sensor boxes from http://ibuttonlink.com./ We did this recently and have been running digitemp from a cron job to log temp and humidity. I'll have to take a look at the nagios plugins to see if one works with digitemp. Otherwise, we were planning on using munin to do some nice rrdtool graphing.
The question of firmware updates extends to devices other than just the motherboard. I recall my CDRW drive having a crappy firmware version and having to update it in order to burn CD's correctly within Linux. It happens. Learning how to build a bootable CDROM with FreeDOS and the firmware program would be well worth the time investment.
Personally, I think hardware manufacturers should make their own little bootable CD images that are OS agnostic to do firmware updates.
And the concept of an OS patch level is foreign to Linux and BSD distributions alike. For all the meaning you might derive from a version number, look at/etc/debian_version. If by OS patch level, you mean a list of possible packages to install and their associated versions, then those are found in a simple text file called Packages in a directory on the archives you request in/etc/apt/sources.list. This file is used to compare the versions of packages installed and packages available. If multiple versions are available, the decision about which version to install is configured in/etc/apt/preferences. It's quite flexible and distributed, perhaps a concept lost on Commercial UNIXes.
So, within the context of Debian, an OS patch level is an active comparison between that which is installed and that which is available. "apt-get install -u" will list the packages that can be updated from the archives you choose to track. "apt-cache policy PACKAGENAME" will give you detail about how available packages are assigned pinning priority, info you can use to see where the package will ultimately be installed from before ever running "apt-get install PACKAGE".
Really, OS Patch Level is a dead concept. My OS patch level is Debian 3.1 with the latest security patches pulled from the security.debian.org archive and a custom kernel...
He was only moderated up 3 points (1 because he didn't post anonymously). At least some of his rating was flamebait. You probably have a +1 bonus for insightful. Downgrade that to 0 if you don't want unwarranted inflation. I find that most "insightful" rankings are overrated anyway and better classified as either "informational" or "interesting" (perhaps).
The subject of the parent is itself suspect of reasonable objectivity. How does one kill a highly successful distribution that is 100% driven by the community at large?
"Take freaking forever to freeze for a release." There were a number of mitigating issues regarding Sarge, not the least of which was creating a new installation suite modular enough to work on all 11 ported architectures (not two dozen). Few can claim more portability. The second largest hold-up was the lack of an autobuild infrastructure for security updates. This was exhaserbated by hardware failures of key buildd daemons, etc. Regardless, time between releases is a sore subject for Debian Developers as well as the users. It is well-discussed on the lists, and in the public archive. Feel free to search debian-release, debian-project, and debian-devel for the relavent discussions.
"Take freaking forever to ship after freezing." I'm not actually sure what was meant by this. The freeze was done in steps, and once the actual freeze was announced, the release happened blazingly fast by most standards. However, this is subjective to POV.
"Ship a broken upgrade even after all the damn testing." How did Debian ship a "broken upgrade?" It created a few ISO images with a typo in/etc/apt/sources.list which prevented updates from an archive that contained no packages yet. What was broken? Additionally, published release notes and detailed installation instructions outlined the difficulties you might find during an upgrade from woody to sarge. What known breakages were hidden from view? What malicious intent did Debian have?
Seriously, to use your phrasology, the above post is nothing more than flamebait. If you don't like Debian's release cycle, either roll up your sleeves and participate in the process to improve it, or jump ship and use something like Ubuntu. Debian is not dead, is not in danger of dying, and could benefit more from helpful contributions than rants about its shortcomings.
I have failed in these posts by feeding the troll. I haven't provided a new defense or pointed out new facts. All of this information is available for those that would search (with little effort, mind you) for it.
Happy hacking, and happy feeding.
Getting a list of packages on debian and the instructions to dselect regarding that package:
dpkg --get-selections > oldlist
Do this before you upgrade. Likewise, if you want to compare files installed pre/post upgrade, make a backup copy of/var/lib/dpkg/info.
cp -rp/var/lib/dpkg/info/var/lib/dpkg/old-info
As per release instructions, upgrade apt first. Then:
apt-get dselect-upgrade or apt-get dist-upgrade
You may need to run apt-get install -f a few times, but apt will tell you when it's necessary. Too much typing? Get over it. Get a list of the resulting packages installed:
dpkg --get-selections > newlist
Compare them:
diff oldlist newlist
Now, to compare files installed per installed package, diff files from your saved/var/lib/dpkg/old-info.
for i in/var/lib/dpkg/info/*.files; do echo "Comparing $i to old version" diff $i ${i/info/old-info} done
Essentially, the info is there for you to use. Debian is an evolving system, so one should learn where the data is and take advantage of that knowledge. Everything is in flat files, easily accessible, and parseable by standard UNIX tools. There are a plethora of useful packages and tools to examine your debian system: grep-dctrl, debian-goodies, apt-listchanges, debsig-verify, etc. For example, one tool that's often ignored is apt-cache. Try this some time:
apt-cache policy PACKAGENAME
Looking for an available package to download? Search the available list for a REGEX that matches descriptions or package names...
They also don't have the resources to making security patches for every package without upgrading to a newer version of said package (i.e. backporting). They really do a phenominal job given their constraints.
I'm not sure what weed you're smoking, but Debian backports ALL of their security fixes from upstream software to the version packaged in stable. Really, consult the Debian Security FAQ for more details.
Slashdot Mirror
I would rather see Comcast improve their DNS server availability first, or at least in addition. For the last three months, I've turned to using another DNS provider because Comcast sees fit to run nightly maintenance on their servers sometime after 01:30 CST. Rarely has connection to the internet been compromised, rather to the DNS servers themselves. If they're using load-balancing hardware, I'm not seeing it as an end-user. Hopefully they can piggy-back a reliable high-availability architecture in addition to DNSSEC...
Back in the day, oh around 1995, my college buddies and I used to play on the Realms of Despair MUD. The Gods that be were heavily improving the codebase and adding new classes. Our favorite class at the time was the Vampire. It seemed to have all of the benefits of a Thief, Mage, and Fighter class all rolled into one.
Instead of mana, vampires used blood points. Young vampires did not have the feed skill, but could drink from a pool of blood created under their slain victims. In any case, there was a bug with the feed skill, probably intended as a feature. When a vampire fed, it both replenished the blood point pool, but also the health points. It took a while to tweak the system to the correct balance, but until then, we had no need of healing spells or potions. Just script tinyfugue or tintin++ to always throw in a few feeds whenever the blood points or health points were getting low, and violla! The most effective attack was to cast invisibility, backstab, feed, and then go into whatever sequence of attack you might have in mind.
Our other favorite bug was to duplicate equipment. Characters and their equipment were not always saved whenever a "transaction" occurred. For example, if a character picked up a sword, the MUD didn't automatically save this to the inventory. Characters were saved periodically, though they could force it through the "save" command.
If you could find a way to crash the MUD (exit a room out a door that didn't exist or some such gem of secret information) you were golden. Character A hands character B a piece of equipment, be it a weapon, gold, or bag containing any number of items. Character B types "save", and A or B then crashes the server. When it comes back up, Character A and B have a copy of the equipment in their inventory.
Of course, the Gods quickly figured this out and started tacking unique serial numbers onto pieces equipment and running periodic audits...
Chewie, a.k.a. Spieler
I am so glad that I read /. occassionally! I was contemplating getting DISH network for our house because of the drastic price savings over the competitors. I had assumed that I could buy/build a Tivo/MythTV box and attach it to my DISH receiver. Now I learn that it isn't going to happen any time soon! Thanks /. for preventing me from making a big consumer mistake!
The type of interface you're thinking about is something along the lines of a text-based MUD or IRC client, where your commands are hooked BEFORE being sent to the server. I personally don't know of any, but can't imagine that it hasn't been considered. Currently, OpenSSH uses the "~" character to indicate that an SSH command will follow. "~C" drops you to an "ssh>" prompt to add things like tunneling while you're still connected to the host. Evidently, the ability to intercept input and redirect it to a local function is already built in to the software. IIRC, you can change the command character if "~" is too clunky for you. The next task is to extend this to provide an alias function. For example, you could bind "~a" to a theoretical "run-alias ALIAS ARGS" command. The desired effect is to output the expanded or constructed shell commands to the host. You will likely want to bind an interpreter to the run-alias command rather than creating your own. Find a license that is compatible with the OpenSSH client or whatever client you might be using.
A friend of mine actually owned a PC when I was in college. He had just gotten a huge 1GB hard drive and was downloading DOOM wads like a madman when he came across the Alien wad. The damn mobs moved so friggin fast. Playing the game with all of the lights turned off, a blanket over my head and monitor, with headphones on literally had me jumping out of the seat when one of the aliens would pop out of its hiding place and rip my face off.
I'm not 100% certain, but I have a vague feeling that you really don't understand BitTorrent. You don't have to leave the client open after you've downloaded your file. You are sharing bits and pieces of the file you're downloading as you're downloading it. For more information on the actual protocol and it's design, visit here.
Just to add this to the suggested list of applications: smartmontools control and monitor storage systems using S.M.A.R.T. lmbench Utilities to benchmark UNIX systems memtest86 Test your memory on x86 platforms nictools-nopci Diagnostic tools for many non-PCI ethernet cards nictools-pci Diagnostic tools for many PCI ethernet cards lm-sensors utilities to read temperature/voltage/fan sensors mbmon Hardware monitoring without kernel dependencies (text client) sensord hardware sensor information logging daemon crashme Stress tests operating system stability fuzz stress-test programs by giving them random input spew I/O performance measurement and load generation tool stress A tool to impose load on and stress test a computer system cpuburn a collection of programs to put heavy load on CPU ltp The Linux Test Project test suite
Find the email address to a local LUG listserv and let them know the stats of the machine and that it's free!
Lucas tried to remove the fantasy element by introducing a biological symbiot to "all living things in the universe". This, of course, is simply hogwash, because eventually we see that ghosts of passed Jedi are allowed to walk appear anywhere they wish. Some geekoid will try to defend ghosts as some "singular expression of a personality though the omnipresent matrix of medaclorians," which so happen to communicate over vast amounts of space instantaneously. This ties together nicely Luke's ability to feel Han's torture and Darth Vadar and the Emperor's ability to coordinate tactical command of vast starfleets.
Hey, it's sci-fi/fantasy; a space opera. If it wasn't, it would be Battle Star Galactica. Suspend disbelief and enjoy.
There's always freshmeat to search for options. EZTorrent appears to be what you want. mod_bt also looks promising if you're using Apache 2.x.
Regarding format, though, I still believe DEB's win for flexibility, accessibility, and a simple, straight-forward design. Baroque is hardly the word to describe the "./debian" maintainer scripts directory. What does one find in "./debian"? control, changelog, copyright, README.Debian, rules (the build Makefile), and optionally the prerm, postrm, preinst, postinst scripts. Whatever else a maintainer puts in that directory that is useful for the build process is entirely subjective to the helper tools they might use (like debhelper).
DEB's are simply two tarballs archived together, data.tar.gz, which contains the package files themselves, and control.tar.gz, which contains the maintainer scripts. If you did not have dpkg installed on your system, but wished to extract the files and information from a DEB, you would simply use the tools ar and tar. To do the same with an RPM is to open up a hex editor to find the end of the RPM header, then use dd to cut it off and output the remaining tarball. (RPM format) How many people know or want to know how to do that?
The other flexiblity that DEB's have that RPM's don't (didn't?) is that maintainer scripts can be written in any language the maintainer wishes, as long as the interpretor is installed at the time the script runs. If you're maintaining a Perl package, it's reasonable to assume that Perl can be installed as a (pre-)dependency and used to run the maintainer scripts.
Debconf, for example, is one of those optional helper tools the maintainer is encouraged to use when questions must be asked of the user/administrator at installation time. Gone are the days when DEB's could not be installed unattended. Using Debconf allows the maintainer to provide those questions, and allows the user to view them using one of multiple interfaces, or to ignore them completely. Additionally, po-debconf makes it trivial to add multilingual support for those questions.
There is plenty of documentation, utilities, and helper tools to create a Debian package, and on-line resources such as IRC, email lists, and forums. An interesting thread to read dates back from 1996, titled "Why the .deb format?". Also, take a gander at this FAQ.
Really, comparing RPM's to DEB's is like comparing apples to oranges. RPM maintainers may baulk at the "debian/" directory and maintainer scripts, but I personally baulk at having to learn yet another spec file format for RPM's and being restricted to using librpm or a hex editor to access the data contained within the package.
Actually, I do think you're wrong, but I am biased in that I'm a Debian Developer. Developers only have to get involved in "politics" if they really wish, but the bulk of developers happily work on the half-a-dozen or so packages they're maintaining and leave the "politics" to the people who care about them. I consider myself amongst this group of moderates, if you wish to pin political terminology upon us.
So really, what is political about security fixes? Nothing, and the mechanisms for updating packages do not revolve around politics either. The basic formula is:
I want you to notice a couple things about this process. The developer is equally responsible as the security team for recognizing a security bug (via watching security bulletins, etc) and for responding to bug reports against his/her package. Even if the patch isn't backported against the Stable package, the developer should notify security@debian.org that there is a problem,
And finally, note how the responsibility for uploading the new binary and source packages lies in the hands of the security team. This is where our concern lies. Is there enough people on the security team to cover 1500+ packages? Probably not. I believe that this is the reason the blog entry was made. Not to undermine or discredit Debian, but to address a shortcoming that can and will be addressed.
If you don't feel like a do-it-yourselfer, you can buy 1-wire temp sensor boxes from http://ibuttonlink.com./ We did this recently and have been running digitemp from a cron job to log temp and humidity. I'll have to take a look at the nagios plugins to see if one works with digitemp. Otherwise, we were planning on using munin to do some nice rrdtool graphing.
The question of firmware updates extends to devices other than just the motherboard. I recall my CDRW drive having a crappy firmware version and having to update it in order to burn CD's correctly within Linux. It happens. Learning how to build a bootable CDROM with FreeDOS and the firmware program would be well worth the time investment. Personally, I think hardware manufacturers should make their own little bootable CD images that are OS agnostic to do firmware updates.
So, within the context of Debian, an OS patch level is an active comparison between that which is installed and that which is available. "apt-get install -u" will list the packages that can be updated from the archives you choose to track. "apt-cache policy PACKAGENAME" will give you detail about how available packages are assigned pinning priority, info you can use to see where the package will ultimately be installed from before ever running "apt-get install PACKAGE".
Really, OS Patch Level is a dead concept. My OS patch level is Debian 3.1 with the latest security patches pulled from the security.debian.org archive and a custom kernel...
He was only moderated up 3 points (1 because he didn't post anonymously). At least some of his rating was flamebait. You probably have a +1 bonus for insightful. Downgrade that to 0 if you don't want unwarranted inflation. I find that most "insightful" rankings are overrated anyway and better classified as either "informational" or "interesting" (perhaps).
http://mitpress.mit.edu/sicp/full-text/book/book.h tml
The subject of the parent is itself suspect of reasonable objectivity. How does one kill a highly successful distribution that is 100% driven by the community at large?
"Take freaking forever to freeze for a release." There were a number of mitigating issues regarding Sarge, not the least of which was creating a new installation suite modular enough to work on all 11 ported architectures (not two dozen). Few can claim more portability. The second largest hold-up was the lack of an autobuild infrastructure for security updates. This was exhaserbated by hardware failures of key buildd daemons, etc. Regardless, time between releases is a sore subject for Debian Developers as well as the users. It is well-discussed on the lists, and in the public archive. Feel free to search debian-release, debian-project, and debian-devel for the relavent discussions.
"Take freaking forever to ship after freezing." I'm not actually sure what was meant by this. The freeze was done in steps, and once the actual freeze was announced, the release happened blazingly fast by most standards. However, this is subjective to POV.
"Ship a broken upgrade even after all the damn testing." How did Debian ship a "broken upgrade?" It created a few ISO images with a typo in /etc/apt/sources.list which prevented updates from an archive that contained no packages yet. What was broken? Additionally, published release notes and detailed installation instructions outlined the difficulties you might find during an upgrade from woody to sarge. What known breakages were hidden from view? What malicious intent did Debian have?
Seriously, to use your phrasology, the above post is nothing more than flamebait. If you don't like Debian's release cycle, either roll up your sleeves and participate in the process to improve it, or jump ship and use something like Ubuntu. Debian is not dead, is not in danger of dying, and could benefit more from helpful contributions than rants about its shortcomings.
I have failed in these posts by feeding the troll. I haven't provided a new defense or pointed out new facts. All of this information is available for those that would search (with little effort, mind you) for it. Happy hacking, and happy feeding.
Downgrade the troll above, please.
I'm not sure what weed you're smoking, but Debian backports ALL of their security fixes from upstream software to the version packaged in stable. Really, consult the Debian Security FAQ for more details.
Yep. It looks like Bram and Co. have flipped the switch and turned off the search site to the general public.