Actually, I find that friends have a less than 60% chance of making a recomendation that I'll like. People like vastly different things, and for different reasons.
However, recommendations from multiple friends raises the accuracy to close to 100%.
This is why the batteries will cost like $200 for a four pack of AA's.
However, they'll still sell like hotcakes, because of the other characteristics, such as very rapid discharge, like the capacitor used in photo flash units, and the ability to work well in the cold.
When I say documentation, I mean the end user manuals. The reference manuals (as opposed to the tutorial) don't need to be highly user friendly to help a great deal in producing a good program to solve a complex problem.
And shouldn't that be "...a project *which* wants help with their docs?":-)
Ugh, No.
If you regard the project as a group of people, it's "who want help with their docs". If you regard the project as a neuter entity, it'd be "which wants help with its docs."
And I suspect regarding the project as people is the right thing to do, especially with regard to wanting help.
I didn't say it cost them nothing to make it, I said it cost them nothing to give it away. Their value is derived by the fact that they made a tool to solve their particular problem. They are paid in the problem being solved.
If they write a crappy manual and open it up to corrections while responding to feedback and rewarding those that give, I suspect the quality of the manual would increase like the software did by getting a larger user base.
This makes the assumption that those offering corrections have the skills to make a good manual. While not impossible, historically, I haven't seen this to be the case.
Let's say I am a software author. I wrote some program to scratch my own itch. Now I need to write a manual for it.
How well am I going to do at this? It's going to be terse and assumptive, because I'm already an expert on my program.
So lets say a friend becomes and semi expert on the program, and expands the manual some. Hey, we're good, right?
No, because the manual still sucks, because neither of them are technical writers, and don't possess the skills.
And a good writer might be interested in writing a better manual for it, but what do they have to gain if they aren't passionate about the program, if they aren't allowed to publish it for money?
You can't buy groceries with accolades.
I mean, good on the author and his friend for realesing the code in to the wild, and helping out everyone, but they got the program they wanted. It's free because it costs them nothing to make it free.
The good writer has to spend time doing the writing, as opposed to earning money some other way.
This is why so much OSS has crappy manuals, and why companies like RedHat and Novell are so important: they pay the writers.
After you have read these books, start with section 1 of the manual pages, read through to section 8 or 9 if it exists.
Then start with the Gnome and KDE help pages, and the info pages, and swear and swear and swear at the rotten uncooperative bastards that can't agree on one documentation format, so I have to go searching all over the place to figure out how to use anything.
Oh, yeah, and then buy everything O'Reilly publishes, and sprinkle in most of Addison Wesley.
But your point is taken. Certainly by that time the Intel platform was well entrenched, though clearly not as well as today. Gateway was a power, as was Dell and Compaq. The Intel platform was wonky, but spreading rapidly. Apple was in the middle of being both great and stupid, and various workstation vendors were falling over due to an inability to compete with Sun and SGI.
At the time it seemed like Sun and SGI were going to divide up the workstation market, Apple was going to hold artsy stuff, and Intel was going to be all about Windoze and the office.
But this was also the time of the rise of Linux, and the BSD's, all of which worked well on intel. And NetBSD was clear proof that an OS could be portable and good.
When I think about it, though, it could be taken as a poetic way of saying the proof of the pudding is in the eating.
It's not an external proof. There is no pudding certification, no pudding board passing out papers decreeing the acceptability of the quality. The proof of the quality of the pudding is in the pudding.
In fact, I'd go as far as to say that my newer phrase is more general! After all, perhaps I'm using my pudding for spackle, or bicycle lubrication.:-)
Maybe it's a different thing, but my understanding is that every non-inlined function call is a context switch. So wouldn't fast context switching make everything faster? (Well, except for code that strenuously avoids it, I guess.)
I won't claim that Professor T is wrong, but the proof is in the pudding. If he could produce a kernel set up with all the bells and whistles of Linux, which is the same speed and demonstrably more secure, I'd use it.
But most design is about tradoffs, and it seems like the tradeoff with microkernels is compartmentalism vs. speed. Frankly, most people would rather have speed, unless the security situation is just untenable. So far it's been acceptable to a lot of people using Linux.
Notably, if security is of higher import than speed, people don't reach for micro-kernels, they reach for things like OpenBSD, itself a monolithic kernel.
"Why? Unless you are disabled. Even then, Thermostats have timers."
Oh, yeah, timers solve everything, because my life runs like a perfect little clock, day in, day out, with no variation. I'm so well regulated, I have a timer on my belt so I don't have to undo it when I hit the head. My front door unlocks, opens, closes and locks automatically, I never have to touch it. I'm in perfect time!
Except now, because this subthread has thrown off my timing. Now I have to go to sleep for 21.5 hours to get back in sync, otherwise I'll miss the bowl.
Actually, the brilliance of this idea is that, if it works, it will drain excess energy from seawater, and thus reduce the number of hurricanes that are produced. We'll effectively be using the entire ocean as a solar collector.
When have you ever seen precise descriptions of an as yet unreleased physical technology? This is the stuff that patents were actually for, where the developments costs are heavily tied to a physical process. I bet their lawyers edit every communication that goes out the door.
Lovely. Listen, is your boy high functioning, or low? Is he the next Temple Grandin, or is he one of the ones that rocks incessantly and can't dress himself at the age of ten?
Just because you find your boy easy to deal with doesn't mean everyone else's kid is the same. Some autistics can survive in the world, many can't. For them amelioration of the effects means not having a "normal" life, but having a shot at any kind of independence.
That, of course, makes me think about the Unix naming conventions, and how little I like them.
Some makes sense, like bin and lib./sbin is the most confused name in Unix. Folks, it means static bin, and is for things which must work even if the shared libraries are broken. It doesn't mean system.
Then there's man. Okay, it stands for manual. Fine. But the man program shouldn't be called "man", it should be "help".
Then there's etc. Grrr. This should be conf, or config. The only things typically in/etc or rc files and global config files. And the rc files basically configure the machine.
We won't talk about Solaris which used to have FIFO's in/etc. I hope they have stopped that egregious behavior.
Then there's libexec. Are the executables or libraries? Oh, they're executables that are meant to be run by other executables only. How about "helper"?
Regarding Emacs:
Let's face it, GNU Emacs is a very short distance from being a complete OS. A message passing kernel and a few drivers (which could be written in elisp) and you're there.
I have set init=/usr/bin/emacs before, just for shits and giggles. It doesn't handle zombies well, though.;-)
Your scheme has merit. The reason I suggest the division is because what I call the basic system apps are also all ones that should be tagged and watched by a tripwire like mechanism to prevent being rooted.
Also, the apps in/bin and friends would be that which is needed for basic booting, so there'd be a nice obvious division for those using the distribution for embedded work.
And frankly, I'd actually put emacs into the/apps hierarchy. It's not universal, and it's huge.
I would put some sort of stripped down emacs like editor in with vi, though.
It's sad that it takes Apple to get the obvious going.
A good system would work as follows:
Base system (everything needed to get the system up into a usuable at all state, but no serious apps beyond vi) in/bin/lib/sbin/etc/man.
The secondary set of basic apps (like grep, find, cut, and so on) in/usr/bin/usr/lib, etc.
Add on apps (like gcc, emacs, Quake3, etc) in mini hierarchies:/apps/gcc/bin/apps/gcc/lib...
Common libraries anywhere convenient (probably/apps/commonlibs/) and soft linked into the lib directory of the mini hierarchy.
The same goes for stuff normally in/usr/share.
If the package can't work without it, it should be softlinked into the mini hierarchy.
The result is that it's extremely obvious what stuff an application needs without having to use special tools and look up possibly outdated docs.
This also means that it's obvious how to do version management. You would have a tool called addpath that would allow you to add an app to your path (or to the system path) and otherwise manage things so that you only had the apps your wanted there, but it'd be very easy to find out what you were missing.
If you installed a new version of something, it would overwrite the old one. It'd just remind you to remove the old path, and put in the new one. That way testing new programs becomes easier.
My suggestion is that IT folks ought to be looking very carefully at the licensing for this stuff, and demanding indemnification against loss in the case that the DRM shit pops up and bites you at a critical time. Having a critical piece of software stop working because some IP wonk at Microsoft decided there was something wrong with your account is decidedly bad.
This really strikes me as a big potential barrier to trade.
In fact, that's not really the case. In house lawyers handle basic business advisement, and coordinate the activities of the outside firms employed. Outside firms specializing in the appropriate activity are employed because they are more likely to be successful in the endeavor.
Law firms routinely send out cease and desists like this. However, the good ones don't do it for clearly non-infringing instances. If they were to claim injury because someone has listed a game as a favorite, they were certainly be laughed out of court.
What's going to happen here is that Nintendo is going to apologize for the dumb law firm, and the dumb law firm is going to grovel at Nintendo feet for giving Nintendo bad PR.
Aside of all the training you should get, a book you should own is "The Practice of Network and Systems Administration". It's not a technical book, it's a book about how to be a great sys-admin.
Since you are making a big switch, you should be thinking about the future, and how to plan for it. This book is an invaluable guide to this sort of planning.
Slashdot Mirror
Actually, I find that friends have a less than 60% chance of making a recomendation that I'll like. People like vastly different things, and for different reasons.
However, recommendations from multiple friends raises the accuracy to close to 100%.
This is why the batteries will cost like $200 for a four pack of AA's.
However, they'll still sell like hotcakes, because of the other characteristics, such as very rapid discharge, like the capacitor used in photo flash units, and the ability to work well in the cold.
When I say documentation, I mean the end user manuals. The reference manuals (as opposed to the tutorial) don't need to be highly user friendly to help a great deal in producing a good program to solve a complex problem.
Ugh, No.
If you regard the project as a group of people, it's "who want help with their docs". If you regard the project as a neuter entity, it'd be "which wants help with its docs."
And I suspect regarding the project as people is the right thing to do, especially with regard to wanting help.
This makes the assumption that those offering corrections have the skills to make a good manual. While not impossible, historically, I haven't seen this to be the case.
Let's think about this, shall we?
Let's say I am a software author. I wrote some program to scratch my own itch. Now I need to write a manual for it.
How well am I going to do at this? It's going to be terse and assumptive, because I'm already an expert on my program.
So lets say a friend becomes and semi expert on the program, and expands the manual some. Hey, we're good, right?
No, because the manual still sucks, because neither of them are technical writers, and don't possess the skills.
And a good writer might be interested in writing a better manual for it, but what do they have to gain if they aren't passionate about the program, if they aren't allowed to publish it for money?
You can't buy groceries with accolades.
I mean, good on the author and his friend for realesing the code in to the wild, and helping out everyone, but they got the program they wanted. It's free because it costs them nothing to make it free.
The good writer has to spend time doing the writing, as opposed to earning money some other way.
This is why so much OSS has crappy manuals, and why companies like RedHat and Novell are so important: they pay the writers.
After you have read these books, start with section 1 of the manual pages, read through to section 8 or 9 if it exists.
Then start with the Gnome and KDE help pages, and the info pages, and swear and swear and swear at the rotten uncooperative bastards that can't agree on one documentation format, so I have to go searching all over the place to figure out how to use anything.
Oh, yeah, and then buy everything O'Reilly publishes, and sprinkle in most of Addison Wesley.
>And I am pretty sure that Linux is the most ported OS in existence.
Actually, I think that honor might go to NetBSD.
But your point is taken. Certainly by that time the Intel platform was well entrenched, though clearly not as well as today. Gateway was a power, as was Dell and Compaq. The Intel platform was wonky, but spreading rapidly. Apple was in the middle of being both great and stupid, and various workstation vendors were falling over due to an inability to compete with Sun and SGI.
At the time it seemed like Sun and SGI were going to divide up the workstation market, Apple was going to hold artsy stuff, and Intel was going to be all about Windoze and the office.
But this was also the time of the rise of Linux, and the BSD's, all of which worked well on intel. And NetBSD was clear proof that an OS could be portable and good.
Thanks for reminding me.
:-)
When I think about it, though, it could be taken as a poetic way of saying the proof of the pudding is in the eating.
It's not an external proof. There is no pudding certification, no pudding board passing out papers decreeing the acceptability of the quality. The proof of the quality of the pudding is in the pudding.
In fact, I'd go as far as to say that my newer phrase is more general! After all, perhaps I'm using my pudding for spackle, or bicycle lubrication.
Maybe it's a different thing, but my understanding is that every non-inlined function call is a context switch. So wouldn't fast context switching make everything faster? (Well, except for code that strenuously avoids it, I guess.)
So you are saying that for microkernels to be fast, you need different hardware? What would the difference be?
I won't claim that Professor T is wrong, but the proof is in the pudding. If he could produce a kernel set up with all the bells and whistles of Linux, which is the same speed and demonstrably more secure, I'd use it.
But most design is about tradoffs, and it seems like the tradeoff with microkernels is compartmentalism vs. speed. Frankly, most people would rather have speed, unless the security situation is just untenable. So far it's been acceptable to a lot of people using Linux.
Notably, if security is of higher import than speed, people don't reach for micro-kernels, they reach for things like OpenBSD, itself a monolithic kernel.
"Why? Unless you are disabled. Even then, Thermostats have timers."
Oh, yeah, timers solve everything, because my life runs like a perfect little clock, day in, day out, with no variation. I'm so well regulated, I have a timer on my belt so I don't have to undo it when I hit the head. My front door unlocks, opens, closes and locks automatically, I never have to touch it. I'm in perfect time!
Except now, because this subthread has thrown off my timing. Now I have to go to sleep for 21.5 hours to get back in sync, otherwise I'll miss the bowl.
Actually, the brilliance of this idea is that, if it works, it will drain excess energy from seawater, and thus reduce the number of hurricanes that are produced. We'll effectively be using the entire ocean as a solar collector.
Ummm, duh?
When have you ever seen precise descriptions of an as yet unreleased physical technology? This is the stuff that patents were actually for, where the developments costs are heavily tied to a physical process. I bet their lawyers edit every communication that goes out the door.
They'll make a mint, if it's true.
Lovely. Listen, is your boy high functioning, or low? Is he the next Temple Grandin, or is he one of the ones that rocks incessantly and can't dress himself at the age of ten?
Just because you find your boy easy to deal with doesn't mean everyone else's kid is the same. Some autistics can survive in the world, many can't. For them amelioration of the effects means not having a "normal" life, but having a shot at any kind of independence.
That, of course, makes me think about the Unix naming conventions, and how little I like them.
/sbin is the most confused name in Unix. Folks, it means static bin, and is for things which must work even if the shared libraries are broken. It doesn't mean system.
/etc or rc files and global config files. And the rc files basically configure the machine.
/etc. I hope they have stopped that egregious behavior.
;-)
Some makes sense, like bin and lib.
Then there's man. Okay, it stands for manual. Fine. But the man program shouldn't be called "man", it should be "help".
Then there's etc. Grrr. This should be conf, or config. The only things typically in
We won't talk about Solaris which used to have FIFO's in
Then there's libexec. Are the executables or libraries? Oh, they're executables that are meant to be run by other executables only. How about "helper"?
Regarding Emacs:
Let's face it, GNU Emacs is a very short distance from being a complete OS. A message passing kernel and a few drivers (which could be written in elisp) and you're there.
I have set init=/usr/bin/emacs before, just for shits and giggles. It doesn't handle zombies well, though.
Your scheme has merit. The reason I suggest the division is because what I call the basic system apps are also all ones that should be tagged and watched by a tripwire like mechanism to prevent being rooted.
/bin and friends would be that which is needed for basic booting, so there'd be a nice obvious division for those using the distribution for embedded work.
/apps hierarchy. It's not universal, and it's huge.
Also, the apps in
And frankly, I'd actually put emacs into the
I would put some sort of stripped down emacs like editor in with vi, though.
It's sad that it takes Apple to get the obvious going.
/bin /lib /sbin /etc /man.
/usr/bin /usr/lib, etc.
/apps/gcc/bin /apps/gcc/lib...
/apps/commonlibs/) and soft linked into the lib directory of the mini hierarchy.
/usr/share.
A good system would work as follows:
Base system (everything needed to get the system up into a usuable at all state, but no serious apps beyond vi) in
The secondary set of basic apps (like grep, find, cut, and so on) in
Add on apps (like gcc, emacs, Quake3, etc) in mini hierarchies:
Common libraries anywhere convenient (probably
The same goes for stuff normally in
If the package can't work without it, it should be softlinked into the mini hierarchy.
The result is that it's extremely obvious what stuff an application needs without having to use special tools and look up possibly outdated docs.
This also means that it's obvious how to do version management. You would have a tool called addpath that would allow you to add an app to your path (or to the system path) and otherwise manage things so that you only had the apps your wanted there, but it'd be very easy to find out what you were missing.
If you installed a new version of something, it would overwrite the old one. It'd just remind you to remove the old path, and put in the new one. That way testing new programs becomes easier.
Appears to remind me of such effectiveness if one were to try and implmenent this.
I have no idea what this is supposed to mean.
My suggestion is that IT folks ought to be looking very carefully at the licensing for this stuff, and demanding indemnification against loss in the case that the DRM shit pops up and bites you at a critical time. Having a critical piece of software stop working because some IP wonk at Microsoft decided there was something wrong with your account is decidedly bad.
This really strikes me as a big potential barrier to trade.
In fact, that's not really the case. In house lawyers handle basic business advisement, and coordinate the activities of the outside firms employed. Outside firms specializing in the appropriate activity are employed because they are more likely to be successful in the endeavor.
Law firms routinely send out cease and desists like this. However, the good ones don't do it for clearly non-infringing instances. If they were to claim injury because someone has listed a game as a favorite, they were certainly be laughed out of court.
What's going to happen here is that Nintendo is going to apologize for the dumb law firm, and the dumb law firm is going to grovel at Nintendo feet for giving Nintendo bad PR.
Aside of all the training you should get, a book you should own is "The Practice of Network and Systems Administration". It's not a technical book, it's a book about how to be a great sys-admin.
Since you are making a big switch, you should be thinking about the future, and how to plan for it. This book is an invaluable guide to this sort of planning.
Limoncelli and Hogan, Addison Wesley
And you can use it to populate an LDAP database?
That was a thing he specifically mentioned.