Eric has requested several in-kernel facilities solely to support his autoconfigurator. Most of these requests have been at the very best ridiculous.
I suppose I'd have no trouble believing this. I'd still like to know what the requests are and why they are ridiculous.
Aunt Tillie shouldn't have to
But.. she does. We don't have runtime autoconfiguration that works in every case. If an autoconfigurator is easy to build, and won't impact the people working on runtime configuration, then why stop them from doing it? My computer should read my mind (or at the least, the pointer should move to the thing my eyes are looking at) but I'm not going to tell people to stop working on improving mouse support.
The autoconfigurator is bound to be an imperfect job
True enough, but this is true for runtime autoconfig as well.
The kernel people are already drowning in bogus bug reports
Kernel bugs are reported via email on the mailing list. This is described in marginal detail in/usr/src/linux/REPORTING-BUGS. Furthermore, it begins with the following dubious paragraph:
What follows is a suggested procedure for reporting Linux bugs. You aren't obliged to use the bug reporting format, it is provided as a guide
to the kind of information that can be useful to developers - no more.
What this document highlights more than anything is that kernel developers are drowning in bug reports because linux kernel bugs are reported in an informal format on the mailing list. Get a proper bug tracking system and it will be much easier to keep track of real bugs. This should be done regardless of whether or not we make "kernels for the masses". I hadn't heard about the bug report problem until you brought it up, and it's frankly amazing that it hasn't been addressed in this manner already.
Let me buy you a sense of humor. No, it's all right, I believe in charity. It's only the standard model, but it's better than nothing which is what you have.
With all that searching America did for Chandra Levy, it's amazing that nobody found her. Doesn't reflect well on the quality of Google as a search engine.
This may seem weird but a disconnected innd can act as a lovely backup server. Simply put a news posting client on every workstation to be backed up. Those workstations can use newspost or similar to post their important files to the server, along with commentary (making it easier to find the right file), timestamps and dates (provided automatically by the server when you post), etc. To back up the server, you backup one directory, where inn stores its files:/var/spool/news/news.archive
Lots of free "backup software" available - e.g. pan, newspost, tin...
Centralized backups over the network! Only one server directory to back up.
Backups are automatically dated by the server, and can be signed and even encrypted if you integrate pgp into your posting script.
Disadvantages:
Posts take up 35% more space than the original file did. This is adequately solved by compressing the inn directory before backing up.
Only solves backing up single-files cases, such as compressed archives. You cannot automatically restore a system to a particular state this way, only individual files. This is optimal for backing up your home directory, sub-optimal for system images. (See here for why this may not matter to you.)
If you need a secure pipe to the backup server, you either have to have a firewall in place (and you should), or you need to provide the encryption layer on your own. NNTP does not "naturally" provide encryption afaik.
This is where Unix's concept and implementation of HOME directory really shines. In the Windows paradigm, things can and do end up anywhere on the system, because you can write anywhere you want to. Application software is under no pressure to write to a standard place so you end up with things in: the desktop, the application's home directory, the user's home directory (if you're in win2k or later), a temp directory, etc. In Unix users have 2 places to write things: $HOME, and/tmp. If you don't want to keep a file around later, just remember not to put it in tmp. Then only back up $HOME. Everything else on your system can be restored automatically from either the net or the CD media that you purchased.
Not to distro-bait, but Debian in particular shines here because apt makes it so damn easy to bring a system back to the state you wanted. For myself I have created a meta-package (.deb) which does nothing but depend on the applications I want installed on every desktop system: galeon, gnucash, xchat, gaim, xmms, vim-gtk, and a handful of others. Then I back up my meta-package, all of 10k including a few shell scripts I wrote for myself. Install my meta-package on a new system, and voilá, apt fetches and installs every app, that I need to continue working, dependencies included.
Mirroring isn't backing up. RAID (-5 or -1, at least, not -0) will protect a working system from hardware failure quite nicely. But it won't protect you from user error. The biggest source of failures in my personal experience has been installing software that destroys your partition, installing software that throws your system configuration into chaos and accidentally deleting or overwriting software that you really, really needed for system operation.
RAID won't protect against those types of accidents. Indeed, RAID will happily mirror your screwup for you, automatically. Real backups, on removable media, are the only way to keep a working copy of your system. A separate, permanent hard drive would work too (although it doesn't provide the mental separation between "secure backup" and "live system" that DVDs or tapes would). The important thing is that you perform your backup manually, at a point when your system is in a "known good" configuration.
So, 2 days before a freeze, you notice this problem, and you're just going to remove all the doc rather than release it anyway? If you were a company, I'd be selling stock.
In my area (SFBay Area) I discovered my service was down only because my statically-configured DNS servers weren't responding any more. Then a day later they were, but I noticed a very strange thing - all queries threw out the same IP address. So I brought up a web browser and went to slashdot.org, and their attbi new user page came up in its place.
The new user page contained information about what had happened and about how to get on the new service. (It also mentioned that they've throttled download speeds at 1.5Mbit, where I was getting 10 before. Feh!) Very weird, but darned if it wasn't a good solution. So I discovered that you have to call them to get static IP information, but as long as dhclient is configured correctly, it'll get the right info for you. After I got my DHCP information everything was golden. I could have switched back to static if I'd wanted to.
DNS for $30 per domain... for life. And if you decide you want to drop a domain and get a different one? $0. You already paid for 1 domain worth of DNS, and that's what you'll get, regardless of what the domain is called.
Of course you still need a registrar. I've had no problems with godaddy.com with my 3 domains.
Joe Sixpack attempts to legally make copies of his own CDs for backup (as I do, with all my CDs). NOW the copy protection makes a difference, because he can't do that.
So he signs on to the net, downloads the copies illegally for backup instead.
So hardcore cracker geek takes down the protection. Coos to all his friends: "I broke it!" Copies the tracks for them. They sign on to Morpheus (so does he). Now tracks are in Joe Sixpack's home, 2 days later. Next week, everyone on the net has them.
Oops.
Protocol implementation
on
XML for Ancients
·
· Score: 2, Informative
Clients would have to know and implement the protocol. But since XML always looks the same, implementing the protocol is just a matter of linking the standard XML library in the language of your choice and using the DTD to decide what you want your client to understand.
I won't comment on your point about having a professional face. But what you say here is interesting:
Sure, you can pick and choose different products, but with Windows you don't have to. If you go with Windows 2000 or XP and Microsoft Office (or just Word) then you don't have to worry about making the wrong choice.
I hate to say it, but you're right. Microsoft software does get the job done almost every time. Linux has clear wins in some areas, mainly the stability (predictability) of the overall system and, of course, price. But with any given piece of software you have to ask, "Does this do everything I need?" You have to ask that question less frequently with Microsoft products, because they're usually the ones defining what everyone else needs by virtue of already having it. They may suck in other areas, but if you need that feature, there's a program for Windows that has it. This is only true in Linux if you install large amounts of software from sometimes obscure sources, meanwhile increasing the complexity of the whole system through adding features piecewise and losing the stability advantage. This isn't always true, and many companies will have the expertise to make Linux and its applications work, and work better, than Windows could ever hope to. But still, you have to ask that pesky question.
Arguably, the above post was +2, Funny. +5, Insightful is just plain bad moderation. Time to break out my red M2 pen.
He obviously doesn't want to be interviewed
on
Torvalds Tells All
·
· Score: 2
Linus isn't trying to pass himself off as interesting. If anything he seems to be actively discouraging these sorts of things, and furthermore he's doing so for the right reason: "I'm not interesting, the code and the philosophy behind it and what you do with it are interesting."
Remember we're only talking about use here, meaning implementation, not access to standards documents. Remember that a patent puts the document in the public domain, but puts the technology under use restrictions. You can't patent something secretly.:-)
I took one CS/software-related class in College. I flunked it. (Technically, I Incompleted it, but it got changed to an F when I decided it would be pointless to complete it.) The rest was Psychology, Rhetoric, History, Biology, Mathematics, Statistics. I became an intern while I was in college for one of the world's biggest (and at the time, most satisfying-to-work) software companies in the world. I've been a fulltime employee there 4 years; I moved from testing/support roles to the real core software design in 2.5 of those years.
Why? I learned how to love knowledge. I was taught that learning is beautiful for its own sake, and thus, I learned. I learned what I was interested in. What I was interested in was computer software; I wrote a fair share in college despite never having taken one class; when I was hired as an intern I wasn't expected to have mad code skillz; what they saw in me was someone who could, and wanted to, learn anything. Generalized learning is good because it shows you how to blur the boundaries between disciplines. If you can learn C++ and Bourne shell, you can learn Java in half the time. Learn all three of those, and you'll be able to pick up Perl in a quarter of the time. The last language I acquired was Python; it took me about a week, but then, it was the eighth language I've learned in the last 5 years (not counting a few oddball niche languages).
The kind of place you want to work for will be screening for the kind of person who has two things: (1) an intermediate understanding of the work domain, in my case the set containing: C++, SQL and basic software design skills; (2) a demonstrable ability to learn across work domains, and pick up the extra skills that will be needed to be more effective. A great employee expands his skills quickly to fill the gaps wherever they may be, and an employer can't predict where they will be. Instead they hire people who they can expect to fill any gap.
Broad work experience is the best indicator of this, but I realize a large chunk of Slashdot's readership is still in college, and they won't have any yet. Here's what you want on your resume after college (if you're going to do what I'm doing):
a few examples of coding projects you've worked on; I included (really quite simple) software I wrote to perform statistical analysis on a Psychology experiment I performed, and an editor I wrote for a MUD (of all things). If you can hand them a CD with the actual functioning code on it, you get bonus points.
Examples of places where you've applied other kinds of learning. Tutoring kids (adults?) in Spanish or Math. The design for the aforementioned experiment had its own bullet point in this category.
You can load up on bullet point 1 if you want. Every code-containing CD you mail out with your resume will get you a call back. But they'll mock you cruelly if you don't have any of bullet #2. No matter what discipline you're in, people who learn quickly are more valuable than people who don't, no matter how their skill depth compares. This is the important point, and it's easy to miss, so pay attention: A broad education reduces the time it takes to learn almost anything.
Use a dual proxy scheme. Proxy 1 is behind your firewall. Whatever you key into your browser get's encrypted by the proxy and passed to an anonymous recipient proxy (one of many chosen at pseudo-random). Anonymous recipient proxy decrypts the info, hits the site, returns the data.
Can you post the addresses of these anonymizers and perhaps a link to software that utilizes them? After all, the more people who use them, the more anonymous they are.
The terrorists onboard manage to swiftly disable/kill the pilots and put their man in the pilot's seat. (This is the most likely explanation; an airline pilot would have to know where the plane was going and what it was going to hit, and would have committed suicide or crashed his plane first since he was going to die anyway.)
Now, with a terrorist in charge, why wouldn't the passengers simply attack the men with knives and take them out? Simple. The terrorists tell them "We're hijacking this plane and flying it to <middle eastern location of your choice>. If nobody gets out of hand you'll all be let go/kept safe as soon as we land. But we terrorists are not afraid to die! If you resist, we will set this plane on a collision course with the ground." Furthermore, the terrorists can be as friendly as possible to the people on board to calm them.
In short, they lie to the passengers and make it sound like sitting back is the safe and reasonable thing to do. The terrorists have absolutely no reason to let the passengers know what's really going to happen to them at the end of the flight. And the passengers have very little reason to suspect it. When has this ever happened before?
Think context switches. The reason why people hate the animated paper clip is not that he's cute, or that he's bloatware. My mom hates the paper clip even though the cuteness appeals to her and she does not know what the word 'bloatware' means. She hates him because he interrupts her when she's working. She learned how to turn him off.
In the same way, GUI tools can interrupt your work process. Going to the mouse to select something from a menu is ok when you have never found the option before. It's unquestionably faster than looking up an option in a man page for many operations that GUI dev tools support. But taking your hands off the keyboard to put them on the mouse is an interruption. If that's the only way you can get to the option (other than switching to your xterm, which entails an even more egregious context switch), or, if that's the only way you've learned how to access the option—which it frequently will be, because that's how the GUI teaches you to do it—you waste cycles. You get distracted. Concentration is broken, and you have to do hand overhead, brain overhead, and searching-for-the-right-spot-to-click overhead.
The keyboard, on the other hand, is under your fingertips. No context switching necessary.
You might think I'm arguing against GUI dev tools. You would be wrong. GUIs are a faster way to learn what tools are available, and even to show you some tools that you might never have found when faced with the black hole of the command line and no prior knowledge. RTFM is fine, but most people read only enough to solve the problem they think they have. A GUI presents lots of options in an easily-digestible and memorizable hierarchical format (if designed with a minimum of care). You'll see a lot more of the tools and options available to you, and that alone can save development time.
This has been said many times before me: context switching slows you down; so does a steep learning curve. One is better for beginners, the other better for experts. But I still believe there is a best-of-both-worlds solution out there. How about these two things:
Every time you switch to the mouse to do something, you get an entry in a history file for that GUI. For example, I just picked Tasks->Tools->History to get to the history window in Mozilla. How about keeping a record of that action around? How about a small menu history listbox on the right edge of the menu. That list box would now contain "Tasks->Tools->History (Ctrl-H)" and if I picked it from that list box, I would again get the History window. If I then did View->Apply Theme->Modern I would get yet another entry in that listbox. This helps you memorize where the things are that you use. It also helps you pick them faster by flattening the choices available and paring down the options to those most likely to be picked again.
The same principle could be applied to toolbar buttons. The listbox could instead say "Button pressed" and display an image of the button and the keyboard shortcut to get to it.
Notice that I included the (Ctrl-H). The keyboard shortcut is still the fastest way to get to that menu item: Leave fingers on keyboard, don't use mouse. That keyboard shortcut ought to burn itself into your brain every time you look at it. How? Make it more important. When you stick something into that menu listbox I just talked about, the keyboard shortcut should appear bright, bold, colorful, and then slowly fade to the same emphasis as the text next to it. You will notice it, but it doesn't interrupt you. You will learn it, and you're more likely to try it next time.
Here I used mozilla as my example of a GUI dev tool, which it clearly is not; in a browser your hand is on the mouse most of the time anyway. You can still see how this would be applied to a GUI IDE though.
There are several good and bad treelike XML editors. Merlot was the best cross-platform one I found. Unfortunately these projects all use the same interface: you must laboriously add each element, click in the right box, type the text, all the while making sure not to break the docbook specification.
We need something better. We need an interface like kword or abiword or lyx, all three of which offer:
a fast, unintrusive text editing interface, and
poor-to-mediocre docbook export from its internal format
but not a single one of which offers docbook/xml import, which is critical if you are writing documentation in XML. XML is designed to be the source, the font from which all formatted, renderable versions (read: pdf, html, rtf, txt, etc.) spring. Hence, it must be the saved version, the one you keep in your source/document control system. The others are just conversions from XML. Yet no editor imports XML! This ought to be the easy part! You just write an XSL stylesheet to convert XML-of-your-choice into your editor's internal format.
Slashdot Mirror
"This is the sort of pedantry up with which I will not put." -- Winston Churchill
No, no, it's "This is the sort of errant pedantry up with which I will not put."
5.2 Earthquake Barely Nudges San Francisco
Are we going to start reporting heavy rainfall in Hawaii next?
I suppose I'd have no trouble believing this. I'd still like to know what the requests are and why they are ridiculous.
Aunt Tillie shouldn't have to
But.. she does. We don't have runtime autoconfiguration that works in every case. If an autoconfigurator is easy to build, and won't impact the people working on runtime configuration, then why stop them from doing it? My computer should read my mind (or at the least, the pointer should move to the thing my eyes are looking at) but I'm not going to tell people to stop working on improving mouse support.
The autoconfigurator is bound to be an imperfect job
True enough, but this is true for runtime autoconfig as well.
The kernel people are already drowning in bogus bug reports
Kernel bugs are reported via email on the mailing list. This is described in marginal detail in /usr/src/linux/REPORTING-BUGS. Furthermore, it begins with the following dubious paragraph:
What this document highlights more than anything is that kernel developers are drowning in bug reports because linux kernel bugs are reported in an informal format on the mailing list. Get a proper bug tracking system and it will be much easier to keep track of real bugs. This should be done regardless of whether or not we make "kernels for the masses". I hadn't heard about the bug report problem until you brought it up, and it's frankly amazing that it hasn't been addressed in this manner already.Let me buy you a sense of humor. No, it's all right, I believe in charity. It's only the standard model, but it's better than nothing which is what you have.
With all that searching America did for Chandra Levy, it's amazing that nobody found her. Doesn't reflect well on the quality of Google as a search engine.
Advantages:
- Standardized TCP-based protocol, uses authentication.
- Lots of free "backup software" available - e.g. pan, newspost, tin...
- Centralized backups over the network! Only one server directory to back up.
- Backups are automatically dated by the server, and can be signed and even encrypted if you integrate pgp into your posting script.
Disadvantages:Not to distro-bait, but Debian in particular shines here because apt makes it so damn easy to bring a system back to the state you wanted. For myself I have created a meta-package (.deb) which does nothing but depend on the applications I want installed on every desktop system: galeon, gnucash, xchat, gaim, xmms, vim-gtk, and a handful of others. Then I back up my meta-package, all of 10k including a few shell scripts I wrote for myself. Install my meta-package on a new system, and voilá, apt fetches and installs every app, that I need to continue working, dependencies included.
RAID won't protect against those types of accidents. Indeed, RAID will happily mirror your screwup for you, automatically. Real backups, on removable media, are the only way to keep a working copy of your system. A separate, permanent hard drive would work too (although it doesn't provide the mental separation between "secure backup" and "live system" that DVDs or tapes would). The important thing is that you perform your backup manually, at a point when your system is in a "known good" configuration.
So, 2 days before a freeze, you notice this problem, and you're just going to remove all the doc rather than release it anyway? If you were a company, I'd be selling stock.
The new user page contained information about what had happened and about how to get on the new service. (It also mentioned that they've throttled download speeds at 1.5Mbit, where I was getting 10 before. Feh!) Very weird, but darned if it wasn't a good solution. So I discovered that you have to call them to get static IP information, but as long as dhclient is configured correctly, it'll get the right info for you. After I got my DHCP information everything was golden. I could have switched back to static if I'd wanted to.
DNS for $30 per domain... for life. And if you decide you want to drop a domain and get a different one? $0. You already paid for 1 domain worth of DNS, and that's what you'll get, regardless of what the domain is called.
Of course you still need a registrar. I've had no problems with godaddy.com with my 3 domains.
Oh, and they're a not-for-profit.
Not if they succeed.
So he signs on to the net, downloads the copies illegally for backup instead.
Oops.
Oops.
Clients would have to know and implement the protocol. But since XML always looks the same, implementing the protocol is just a matter of linking the standard XML library in the language of your choice and using the DTD to decide what you want your client to understand.
There's other advantages, but that's a big one.
I hate to say it, but you're right. Microsoft software does get the job done almost every time. Linux has clear wins in some areas, mainly the stability (predictability) of the overall system and, of course, price. But with any given piece of software you have to ask, "Does this do everything I need?" You have to ask that question less frequently with Microsoft products, because they're usually the ones defining what everyone else needs by virtue of already having it. They may suck in other areas, but if you need that feature, there's a program for Windows that has it. This is only true in Linux if you install large amounts of software from sometimes obscure sources, meanwhile increasing the complexity of the whole system through adding features piecewise and losing the stability advantage. This isn't always true, and many companies will have the expertise to make Linux and its applications work, and work better, than Windows could ever hope to. But still, you have to ask that pesky question.
Arguably, the above post was +2, Funny. +5, Insightful is just plain bad moderation. Time to break out my red M2 pen.
Linus isn't trying to pass himself off as interesting. If anything he seems to be actively discouraging these sorts of things, and furthermore he's doing so for the right reason: "I'm not interesting, the code and the philosophy behind it and what you do with it are interesting."
Very...Buddhist, I think.
Remember we're only talking about use here, meaning implementation, not access to standards documents. Remember that a patent puts the document in the public domain, but puts the technology under use restrictions. You can't patent something secretly. :-)
Why? I learned how to love knowledge. I was taught that learning is beautiful for its own sake, and thus, I learned. I learned what I was interested in. What I was interested in was computer software; I wrote a fair share in college despite never having taken one class; when I was hired as an intern I wasn't expected to have mad code skillz; what they saw in me was someone who could, and wanted to, learn anything. Generalized learning is good because it shows you how to blur the boundaries between disciplines. If you can learn C++ and Bourne shell, you can learn Java in half the time. Learn all three of those, and you'll be able to pick up Perl in a quarter of the time. The last language I acquired was Python; it took me about a week, but then, it was the eighth language I've learned in the last 5 years (not counting a few oddball niche languages).
The kind of place you want to work for will be screening for the kind of person who has two things: (1) an intermediate understanding of the work domain, in my case the set containing: C++, SQL and basic software design skills; (2) a demonstrable ability to learn across work domains, and pick up the extra skills that will be needed to be more effective. A great employee expands his skills quickly to fill the gaps wherever they may be, and an employer can't predict where they will be. Instead they hire people who they can expect to fill any gap.
Broad work experience is the best indicator of this, but I realize a large chunk of Slashdot's readership is still in college, and they won't have any yet. Here's what you want on your resume after college (if you're going to do what I'm doing):
You can load up on bullet point 1 if you want. Every code-containing CD you mail out with your resume will get you a call back. But they'll mock you cruelly if you don't have any of bullet #2. No matter what discipline you're in, people who learn quickly are more valuable than people who don't, no matter how their skill depth compares. This is the important point, and it's easy to miss, so pay attention: A broad education reduces the time it takes to learn almost anything.
Can you post the addresses of these anonymizers and perhaps a link to software that utilizes them? After all, the more people who use them, the more anonymous they are.
I kind of like that. Double-fast FireWire=FireFire.
The terrorists onboard manage to swiftly disable/kill the pilots and put their man in the pilot's seat. (This is the most likely explanation; an airline pilot would have to know where the plane was going and what it was going to hit, and would have committed suicide or crashed his plane first since he was going to die anyway.)
Now, with a terrorist in charge, why wouldn't the passengers simply attack the men with knives and take them out? Simple. The terrorists tell them "We're hijacking this plane and flying it to <middle eastern location of your choice>. If nobody gets out of hand you'll all be let go/kept safe as soon as we land. But we terrorists are not afraid to die! If you resist, we will set this plane on a collision course with the ground." Furthermore, the terrorists can be as friendly as possible to the people on board to calm them.
In short, they lie to the passengers and make it sound like sitting back is the safe and reasonable thing to do. The terrorists have absolutely no reason to let the passengers know what's really going to happen to them at the end of the flight. And the passengers have very little reason to suspect it. When has this ever happened before?
In the same way, GUI tools can interrupt your work process. Going to the mouse to select something from a menu is ok when you have never found the option before. It's unquestionably faster than looking up an option in a man page for many operations that GUI dev tools support. But taking your hands off the keyboard to put them on the mouse is an interruption. If that's the only way you can get to the option (other than switching to your xterm, which entails an even more egregious context switch), or, if that's the only way you've learned how to access the option—which it frequently will be, because that's how the GUI teaches you to do it—you waste cycles. You get distracted. Concentration is broken, and you have to do hand overhead, brain overhead, and searching-for-the-right-spot-to-click overhead.
The keyboard, on the other hand, is under your fingertips. No context switching necessary.
You might think I'm arguing against GUI dev tools. You would be wrong. GUIs are a faster way to learn what tools are available, and even to show you some tools that you might never have found when faced with the black hole of the command line and no prior knowledge. RTFM is fine, but most people read only enough to solve the problem they think they have. A GUI presents lots of options in an easily-digestible and memorizable hierarchical format (if designed with a minimum of care). You'll see a lot more of the tools and options available to you, and that alone can save development time.
This has been said many times before me: context switching slows you down; so does a steep learning curve. One is better for beginners, the other better for experts. But I still believe there is a best-of-both-worlds solution out there. How about these two things:
The same principle could be applied to toolbar buttons. The listbox could instead say "Button pressed" and display an image of the button and the keyboard shortcut to get to it.
Here I used mozilla as my example of a GUI dev tool, which it clearly is not; in a browser your hand is on the mouse most of the time anyway. You can still see how this would be applied to a GUI IDE though.
We need something better. We need an interface like kword or abiword or lyx, all three of which offer:
but not a single one of which offers docbook/xml import, which is critical if you are writing documentation in XML. XML is designed to be the source, the font from which all formatted, renderable versions (read: pdf, html, rtf, txt, etc.) spring. Hence, it must be the saved version, the one you keep in your source/document control system. The others are just conversions from XML. Yet no editor imports XML! This ought to be the easy part! You just write an XSL stylesheet to convert XML-of-your-choice into your editor's internal format.