In the late 1970's I read a paper that described the theory behind this. It's cool to see that someone has actually done it. I cannot recall where I read that paper, unfortunately. I was a wild and crazy college student so things like where it was published weren't important to me. I don't think it was in an academic journal, though.
The way this paper did describe the practical potential was in terms of unwound tape. They suggested using the backing medium from magnetic tape, but without the magnetic coating. The proposed mechanism would be to roll the tape past the heads like any tape device, but the heads would be a laser with a high speed rotating mirror that would cause a transversal scanning of the tape. I suspect this thinking was from video tape technology (2 inch quadraplex video tape recording was still common in TV broadcast at that time, EIAJ was getting cheaper, and Beta/VHS was emerging).
There were two interesting aspects of that paper. One was that they suggested a 1/4 inch by 2400 foot reel of tape could eventually hold 10 TERAbits of data (I think DVD has passed this level already, in terms of bits per square mm). The other was that they suggested certain chemical doping of the medium could allow a finite (they suggested 100 times) amount of erasing and rewriting (they didn't detail how that would be done).
I'm just not the kind of person who is oriented to doing things that way. Interesting that you mention type checking as I prefer programming languages with as little as possible. I put up with what is in C, despise Pascal, avoid C++, grumble at Perl, and find PHP and Pike more fun. I guess maybe this comes down to a difference in personality types?
Part of the process of making an RPM from the tarball is to compile and install it anyway, then identify what got installed so that can be integrated into the package.
Oh look what I get when I "install" a SRPM... a source tarball.
I've done these things and made the investors in Advil more money.
That's the fault of the applications. People who write software should learn that just putting files everywhere is a pain for the system administrator. Then they want us to make every system look identical.
Hopefully I can get my questions answered without starting a flamewar. I guess we'll see...
Well, hopefully one doesn't start and spoil an interesting discussion that we could have
Then Debian and RedHat arrived, and I realized how out-of-control things had been under Slackware (and also Solaris and SunOS). The ability to have a tool justify the existance of every file installed on my system was amazing from a sysadmin's viewpoint. And more than that, I could find out what other programs depended on it. This was wonderful, especially for shared libraries.
Do you want that tool to require you to be in front of, or connect to, each and every machine individually, just to configure your network? While having the tools is great when administering one machine, as long as the tools work well and let you do everything you want to do (something I found lacking), what about administering a whole network? The solution I have found is that I need to build a lot of my own scripts. I want things to take care of themselves as much as possible so my script tend towards automating. Fortunately I can just ignore the GUI tools. However, I do have to measure a system I might choose on the basis of how easy it will be to make those scripts work (among other things). Slackware's simplicity makes it the winner more often (though not always).
Because of this experience, I've never really looked back at Slackware. But is it true that Slaskware now has some sort of package management? I must admit I don't really like the convolutions built into the RedHat configuration files -- does Slackware still do this better? Will Slackware warn me if I try to uninstall some part of the system that some other part depends on? Can I tell Slackware that it isn't allowed to install over a particular file (because I've done something special with it?)
What I have always advocated is that as many packages as possible (and I believe that to be most, including all end user applications) should be entirely installable by putting all their files into a directory somewhere (/opt seems appropriate) named according to the package. Deleting a package would be a matter of doing rm -fr on that directory. Everything else should be designed and implemented to be smart enough to figure out how to deal with dependent packages in context. That means, if it can do something better if the other package is present, check to see if it is present and do so, else do the same old thing. If it absolutely has to have it, check to see if it is there and give a clear explanation if not. I really don't see that much need for package management if things are organized right (which they have not been throughout the history of computers).
No, Slackware will not warn you about uninstalling dependency resources. One of the things I have learned through years of supporting mainframes and UNIX, and dealt with MS Windows, is that when you start uninstalling things, reinstalling things, upgrading new versions, and the like, what you end up with is a messed up computer. Sure, package management attempts to address this. But why uninstall it in the first place? Disk space is cheap. Buy a bigger harddrive.
With one exception, I've always installed everything when I install any Linux system, and for the most part have done so with BSD/OS, IRIX, and Solaris. I did once upgrade an Redhat 5.1 system with 5.2. Although there were no dependency or other package problems, the machine just never did run right afterwards. I backed up my own files, wiped off the drives, and reinstalled Redhat 5.2 from scratch (everything) and then it worked fine.
My recommendation is to do planning. Decide what you do need and what you don't need in a new system. Install everything you do need. Do not uninstall anything you don't need. When it's time to upgrade, install the new version from scratch. If this machine needs to be up all the time, do that on a different machine and let them trade places when ready, or perhaps one service at a time (giving each service its own IP address in advance makes that easier to do). Of course not everyone has spare machines around to do this, so it can't be a universal solution. But the more it becomes an accepted practice, the more such machines can become available (if you can sell management on the idea of 99.99% uptime during the transition).
That probably will happen. Right now it's all experimental. I'm running it on production servers only because I can be right there to monitor it. There is just a little bit of conversion to be done to the daemon scripts but that means they have to be tested. Since I don't run all the services that come in most distributions I'm not the best person to test them. I guess it would help to have a few more people trying it out who could add more scripts and test things out to make sure its not goofed up somewhere. I'm just not sure where is the place to post something that's technically still in development. Any ideas? Would freshmeat.net be right for that?
I'm not sure if I will like LSB or not. But if it adopts XML for the config file formats, you can be sure that I will not like it at all, and not use it at all.
What would be best is to provide for diversity. XML seems fine for programmatically generated data, such as from GUI config programs (which I don't use), although HDF doesn't seem to detract from any of the capabilities, although it is a lot easier to manually type in for those of us that prefer to configure our systems with vi/pico/jed/emacs or such. The existing config files also work reasonably well.
Having used Redhat and RPM for 3 versions, and now back to Slackware, I'll let you know that the packaging system was one of the major reasons I came back.
Still, people are different just as you and I are obviously different in what we want in a system. The ideal system is one where we both can do it the way each of us prefers.
But Slackware *is* easy! Trae McCombs even said he was very impressed with the ease of installation. And I think we set up the desktop (at least on KDE) with the nicest set of defaults. But I understand what you're saying -- many of the other distributions now provide a fully graphical installation. But, then you end up raising the hardware requirements, so it's a trade off. I do think keeping things primarily text based is the most flexible, then you can do things like installing with a serial console, and maintaining the machine remotely is more straightforward. Of course, I've been accused of being one of those "command line" kind of people...
I recently set up one of those graphical Linux systems just to see how it worked. I tried Best Linux. One thing I noticed about it was that it was installing stuff in the background while I was going through the interactive Windows9X look-alike screens to give my configuration info. The install was pretty, but you can do all that in text mode as well. The only reason I see to do that is to ease the transition for people who have spent their entire computing life shackled to MS Windows.
What I ended up with, however, was mostly a Redhat look-alike. It appeared to have all the same problems of Redhat, although to be fair, I didn't have time to finish looking it over as I needed that hardware for some real work the next day (and installed Slackware for that).
David Cantrell is working on an experimental packaging system that would have a lot of advantages over our current system (or any other). It would track the user's config files and make it easy to transfer packages and configuration between their own systems. But, we're still evaluating it. It looks like the LSB is going to want everyone to use RPM, so we have to take that into account.
I've been using Slackware since around 2.0 or so. At around 3.4 I acquired a used Sun Sparc 5, and there being no Slackware for it, I gave Redhat 5.1 a try and it seemed OK. I then put Redhat 5.2 on a few machines. As I was getting more and more extensive in making system changes to automate more administrative processes, Redhat eventually became more and more of a pain and 6.0 was my last Redhat. I moved back to Slackware at 4.0 about 1 week before 7.0 came out, but quickly switched to 7.0. I still have 3 machines running Slackware 3.4 so I guess I never really abandoned it. OTOH, there's still 1 running Redhat 5.2 and 1 running Redhat 6.0.
One thing that I disliked greatly about Redhat was the RPM system. While it did allow a nice quick install of a package I did not have before, it really screwed me over with dependency stuff. I frequently update stuff, and on occaision, I was trying to update something a lot of other stuff depended on, and could not because of the dependencies. I was doing the updates from original sources, not RPMs, so the dependencies had to be forcibly removed and the old package deleted for the time being. Then future packages could not install because the dependencies were now screwed up.
RPM basically came across to me as a lock-in feature. That means, once I start using it, I have to keep using it to get any benefit from it. That also means, I have to wait for updates to come out in RPM format before I can upgrade something if I want to keep my RPM DB consistent. I would really much prefer that the presence or absence of a package be predicated on whether the package actually is installed, not whether some DB entry says it must be. I really dislike it when a DB that claims things is out-of-sync with reality, and that is a problem I encountered with the Redhat Package Management system.
I also found problems in making changes to the RC scripts in Redhat. In order to make some daemon scripts work right, I had to modify some of the core functions because they were in the way. Then other stuff broke. It became a nightmare. OTOH, I wasn't entirely happy with the BSD traditional RC scripts that Slackware uses, either. About a month and a half ago, someone on IRC challeneged me with "So just write your own rc scripts, then". So I decided to do so. It was Slackware that served as the foundation to do that because Slackware is still the easiest to change things in the system. What I ended up with was a daemon-script based system in the sense of separate files for each daemon, but with everything in a single subdirectory in/etc without the symlinks. Now the entire setup of what scripts run in what order in what runlevels are easily listed all at once. And now I don't get cut off from the machine when I change run levels from a remote connection.
I'm not saying that Slackware should become like that. What I am saying is that Slackware makes a great foundation for any of us to try out our own ideas on how things should be, especially if you, like me, prefer keeping things uncomplicated. BTW, I've been running my new RC script scheme on a few machines now and it works like a charm. It looks like I'll eventually be converting everything over to it.
Keep up the good work Patrick, David, and all the other folks at Slackware!
Actually it is more likely the case that the best programmers tend to avoid, or leave, companies that place more emphasis on using lawyers as a tool of harassment.
We need a law that says that court costs must be paid for by the plaintiff when seeking judgements in cases out of jurisdiction (e.g. a waste of court time that could be better spent locking real criminals up behind bars).
There was no indication in the ruling (although there appeared to be an assumption) that the same person listed as the contact also offered it for auction.
This could well have been a case where one person registered it with the intent of speculating and/or squatting, or maybe even had a legitimate intent to use that fell through, but entered an incorrect contact handle when registering it (and may not have noticed). The person who did get listed could not really legally act as the owner since he was not the registrant. By his refusal to transfer the domain, he avoided liability to the registrant, who may have had a legitimate use for the domain (the contact may not have known the registrant was offering it for auction).
It is very common for people to be entering new registrations, and while trying to enter their own contact handle, goof and transpose a digit or letter and accidentally "give" it to someone else.
I've had to fix things like this for customers a few times already. It happens and it's not uncommon.
If such a thing does happen to a domain, correct entry of working servers can cause the web site to actually work despite the wrong contact. Further, the real "owner" may be totally unaware the error even exists. Since his name is not on it, it could be hard to track him down.
Imagine yourself in a position where someone registers a domain and accidentally makes YOU the contact for it. Then when someone who has a trademark approaches you and says they want the domain, you just sign the papers and hand it over to them. Then it turns out the registrant also had a trademark or other legitimate use, and now sues YOU for damages.
This is probably not much different that laws on lost property. If you give the property to someone else, you could be accused of transferring property that is not yours. If you sign your name to papers to do the transfer (as would be the case for a domain) then the situation is even worse.
One of the problems with certification is that employers tend to NOT want to pay you any (or much) more once you do get certified (assuming they hired you before being certified, and wanted you to get certified afterwards). Perhaps this is because employers (managers) themselves don't really see any value to the certification in the sense of valuing you as an employee, though they often do see the value in terms of customer relations. What this means is that to am employer, certification of an employee is something to tally up and brag about to a client or potential client, and is quickly forgotten about when your next salary review comes up. I see more demand for certification in body shops (e.g. consulting firms), whether that be Microsoft, Sun, Oracle, Baan, PeopleSoft, Lotus, Cisco or Redhat. I see less of that demand when the employer is not in the business of peddling warm bodies to other businesses.
Consider this. If the consulting firm is presenting themselves to a client, who's reputation are they trying to present and bolster when they do this? Certainly not the reputation of the individual who will end up coming out there for are short time to work. There are some exceptions, but that's generally when the person being presented has something even better than a certification, such as a Ph.D., or they were on the development team of the product they are consulting for.
Pick one of the better known Linux developers whose name you know. Now imagine some Linux consulting business manages to get them on staff or as a partner. Of course when they present to a potential client that needs such a person, they will point the praises directly to them. The certification, if they even have one, probably won't even be mentioned (although they surely won't forget to add it to the tally sheet for other clients). For the rest of us in other situations, we're just numbers on a tally sheet that gets presented to the clients as part of the reputation building of the company itself.
This is the unfortunate of how business does work. There isn't much else that can be done when company A wants to build its reputation to company B in order to get company B's business. As evil as many of us want to think of certification (and it probably got that reputation from the way a couple of other companies were handing them out) it is about the only thing business has to go on when you're looking at the third party consulting market.
What Redhat is doing, by charging much higher fees, and making the test much tougher, is probably an effort to avoid dilution of the certification value. I can tell you this. If I was hiring an NT administrator, and two candidates both had one year experience working with NT in an administrative capacity, and one had an MCSE while the other had a CCIE, I'd hire the CCIE in a heartbeat and sleep well that night. Cisco has done well to make sure their certification program represents the value of the people that earn it. Maybe Redhat is actually trying to do just that, too.
Because the bad guys have 'em, and use 'em, the good guys have to have 'em, too. The trouble is, if you pull yours out and use it first, you're now a bad guy.
I did this in 1996 when I was building a shopping cart for collecting tax forms. It didn't work very well because it messed up DNS, foobarred my test proxy server, and confused the firewall. I wish I had some evidence of the prior art, but it was actually a stupid idea and would have prevented my site from achieving the performance levels it did, so I did the thing that seemed right at the time and abandoned it.
I'll say "Thank you" when there is something to give thanks about.
Lost of people and lots of businesses can put together several machines and run a few different Linux distros and a few BSDs. Far fewer can make a true universal platform farm (the better term is "lab"). A company like VA Linux has the resources to not just to the corner cases, but also fill in all the gaps. If they are true to their word they will, and they won't have any doubts about it up front.
Re:How did the whole domain "ownership" come about
on
Master Of Your Domain
·
· Score: 1
What makes you think that new TLDs would be complicated? They would simplify a lot of things.
Who needs those ICANN controlled root servers, anyway?
You can actually run your own root server. Then you have total control over what TLDs will be present and which registry supplies the zone data. All that is needed is for you know how the name servers to point to for the traditional and national TLDs, if you even want to carry them.
A couple years ago I created a concept I called Grass Roots Servers. The idea was that the root servers would really be run as described above. I came up with this idea because of the issue of deciding who would be the one to supply zone data for a new TLD. Since I didn't want political cronies or mega corporations making the decision for everyone, and I didn't want to be making that decision, either (as if I could), I figured the best place to decide was as close to each user as possible. One interesting thing about this is the fact that nothing has to be done by any sort of political or corporate power to enable it.
The difficulty in such a thing is that most people don't want to deal with the complexity of dealing with finding all the TLD name servers, and building the appropriate zone data file. That's where I came up with the web site Grass Roots Servers which would be a way to select the TLDs you want to have, or don't want to have, and have a zone file built for you. If the idea caught on, surely more tools would be created that just my first attempt, of which source can be downloaded if you want. Keep in mind I did this a couple years ago and have not updated it. The data is kind of old, but some of it may work.
So, do you want them to control your view of the domain name system, or do you want to control it yourself?
Actually, I'd love to buy from VA Linux, but I also want, if I stop building my own and buying pre-built machines, to get all my needs from one source. Unfortunately, VA Linux doesn't have enough of a product line to suit my needs, yet. I want something from VA Linux that competes with IndyBox's 1U servers.
First, this is not a web-only service. We do like to provide web interfaces to as much as possible, but we do realize that for some things, program compliation and testing included, nothing can substitute for shell access.
Will special permission be needed to get to shell access, or will anyone who signs up with a project have this option?
A lot of people are asking about other hardware architectures and OS's. For now, the Compile Farm is i386 based, and contains several Linux distributions and FreeBSD. This does not mean that we have ruled out other possibilities. This is just another step in what we hope can be an expanding feature set for Open Source developers on SourceForge.
You need to not just not rule out other possibilities, you need to make a firm commitment to them. There needs to be, paraphrasing from those TV commercials I've been seeing, every operating system... on every platform. That means not just FreeBSD, but also NetBSD and OpenBSD. That means each BSD on each hardware platform it runs on. That means not just Redhat Linux, Debian GNU/Linux, Slackware, SuSE, Best Linux, Turbo Linux. That means each Linux on each hardware platform it runs on, including S/390. That means not just open source operating systems, but also commercial operating systems. That means AIX, HP/UX, Solaris, and others. That means each platform they run on (e.g. Solaris on Sparc, Solaris on UltraSparc, Solaris on x386, etc).
There's already efforts to make some open source programs available on Solaris here.
There is a lot of setup involved in something like this Compile Farm, not the least of which is having thousands of skilled Open Source developers with shell accounts on a set of boxes. We're attempting to keep things as secure as possible while also offering enough features to make this thing useful. One reason for the limited number of distributions/architectures/OS's now is the limitation of variables in a very complex system. Hopefully, we can work out the kinks in this system soon so that it can become a valuable resource to developers who might not otherwise have the capability of getting their hands on so many different machines.
Make the commitment to at least a few platforms that VA Linux does not sell, so we know you are serious and that this is not just a scheme to market your hardware and that you actually intend to make this the thing you claim it to be. Also, will you commit to having SourceForge on early Itanium machines as soon as you can get them from Intel?
I'm sure there are a lot of issues you have to work with, security being the most critical. For example, what if the project requires root access (some programs need to be SUID root for users, and some are tools for system administration). I know it won't be easy.
Please be patient as we test this new system. We're definately open to criticism, but please also be constructive with it so that we can continue to improve these services. Thanks to all of the SourceForge users who have contributed patches, criticism, and helpful suggestions. Every day my confidence in the Open Source model increases...
So get a few Sparc and Alpha boxes, put them behind a tight firewall which prevents people from getting out execpt via their own SSH tunnel, put BSD, Linux, and Solaris up as appropriate, and just let it go as a little "glass world" experiment so you can at least see what the issues are you'll have to deal with.
If the drive heads warmed up less than the platters, the differential expansion due to thermal changes would surely distort the spacing and change the character of the way the heads ride over the platter airflow. A difference in the temperature between the air and heads could also be a source of potential problems. I have doubts they specifically cool the heads. But perhaps they do have coolant running through everything, or maybe the outer frame.
The heat sources would be the electronics (mostly underneath, but some are inside, such as the head pre-amps), the platter motor, and the voice coil. The better the bearings are, the lower the resistance to spin, and the less energy required to maintain RPM. But at higher RPM, the resistance increases by some formula I have long forgotten, so there will still me more energy needed, and thus more heat dissipated, to maintain RPM. Lighter platters would also help, but I'm not sure just to what degree this is once the drive has spun up. Head seeking needs to be faster and faster to meet our demands and expectations, too, and that means more energy in the voice coil to increase the acceleration.
So, they will be very hot! But will the heads specifically need to be cooled? I doubt it. And running coolant out to the heads would likely weight them down a whole lot.
Slashdot Mirror
In the late 1970's I read a paper that described the theory behind this. It's cool to see that someone has actually done it. I cannot recall where I read that paper, unfortunately. I was a wild and crazy college student so things like where it was published weren't important to me. I don't think it was in an academic journal, though.
The way this paper did describe the practical potential was in terms of unwound tape. They suggested using the backing medium from magnetic tape, but without the magnetic coating. The proposed mechanism would be to roll the tape past the heads like any tape device, but the heads would be a laser with a high speed rotating mirror that would cause a transversal scanning of the tape. I suspect this thinking was from video tape technology (2 inch quadraplex video tape recording was still common in TV broadcast at that time, EIAJ was getting cheaper, and Beta/VHS was emerging).
There were two interesting aspects of that paper. One was that they suggested a 1/4 inch by 2400 foot reel of tape could eventually hold 10 TERAbits of data (I think DVD has passed this level already, in terms of bits per square mm). The other was that they suggested certain chemical doping of the medium could allow a finite (they suggested 100 times) amount of erasing and rewriting (they didn't detail how that would be done).
I'm just not the kind of person who is oriented to doing things that way. Interesting that you mention type checking as I prefer programming languages with as little as possible. I put up with what is in C, despise Pascal, avoid C++, grumble at Perl, and find PHP and Pike more fun. I guess maybe this comes down to a difference in personality types?
Part of the process of making an RPM from the tarball is to compile and install it anyway, then identify what got installed so that can be integrated into the package.
... a source tarball.
Oh look what I get when I "install" a SRPM
I've done these things and made the investors in Advil more money.
That's the fault of the applications. People who write software should learn that just putting files everywhere is a pain for the system administrator. Then they want us to make every system look identical.
Well, hopefully one doesn't start and spoil an interesting discussion that we could have
Do you want that tool to require you to be in front of, or connect to, each and every machine individually, just to configure your network? While having the tools is great when administering one machine, as long as the tools work well and let you do everything you want to do (something I found lacking), what about administering a whole network? The solution I have found is that I need to build a lot of my own scripts. I want things to take care of themselves as much as possible so my script tend towards automating. Fortunately I can just ignore the GUI tools. However, I do have to measure a system I might choose on the basis of how easy it will be to make those scripts work (among other things). Slackware's simplicity makes it the winner more often (though not always).
What I have always advocated is that as many packages as possible (and I believe that to be most, including all end user applications) should be entirely installable by putting all their files into a directory somewhere (/opt seems appropriate) named according to the package. Deleting a package would be a matter of doing rm -fr on that directory. Everything else should be designed and implemented to be smart enough to figure out how to deal with dependent packages in context. That means, if it can do something better if the other package is present, check to see if it is present and do so, else do the same old thing. If it absolutely has to have it, check to see if it is there and give a clear explanation if not. I really don't see that much need for package management if things are organized right (which they have not been throughout the history of computers).
No, Slackware will not warn you about uninstalling dependency resources. One of the things I have learned through years of supporting mainframes and UNIX, and dealt with MS Windows, is that when you start uninstalling things, reinstalling things, upgrading new versions, and the like, what you end up with is a messed up computer. Sure, package management attempts to address this. But why uninstall it in the first place? Disk space is cheap. Buy a bigger harddrive.
With one exception, I've always installed everything when I install any Linux system, and for the most part have done so with BSD/OS, IRIX, and Solaris. I did once upgrade an Redhat 5.1 system with 5.2. Although there were no dependency or other package problems, the machine just never did run right afterwards. I backed up my own files, wiped off the drives, and reinstalled Redhat 5.2 from scratch (everything) and then it worked fine.
My recommendation is to do planning. Decide what you do need and what you don't need in a new system. Install everything you do need. Do not uninstall anything you don't need. When it's time to upgrade, install the new version from scratch. If this machine needs to be up all the time, do that on a different machine and let them trade places when ready, or perhaps one service at a time (giving each service its own IP address in advance makes that easier to do). Of course not everyone has spare machines around to do this, so it can't be a universal solution. But the more it becomes an accepted practice, the more such machines can become available (if you can sell management on the idea of 99.99% uptime during the transition).
That probably will happen. Right now it's all experimental. I'm running it on production servers only because I can be right there to monitor it. There is just a little bit of conversion to be done to the daemon scripts but that means they have to be tested. Since I don't run all the services that come in most distributions I'm not the best person to test them. I guess it would help to have a few more people trying it out who could add more scripts and test things out to make sure its not goofed up somewhere. I'm just not sure where is the place to post something that's technically still in development. Any ideas? Would freshmeat.net be right for that?
I'm not sure if I will like LSB or not. But if it adopts XML for the config file formats, you can be sure that I will not like it at all, and not use it at all.
What would be best is to provide for diversity. XML seems fine for programmatically generated data, such as from GUI config programs (which I don't use), although HDF doesn't seem to detract from any of the capabilities, although it is a lot easier to manually type in for those of us that prefer to configure our systems with vi/pico/jed/emacs or such. The existing config files also work reasonably well.
IIABDFI.
Having used Redhat and RPM for 3 versions, and now back to Slackware, I'll let you know that the packaging system was one of the major reasons I came back.
Still, people are different just as you and I are obviously different in what we want in a system. The ideal system is one where we both can do it the way each of us prefers.
I recently set up one of those graphical Linux systems just to see how it worked. I tried Best Linux. One thing I noticed about it was that it was installing stuff in the background while I was going through the interactive Windows9X look-alike screens to give my configuration info. The install was pretty, but you can do all that in text mode as well. The only reason I see to do that is to ease the transition for people who have spent their entire computing life shackled to MS Windows.
What I ended up with, however, was mostly a Redhat look-alike. It appeared to have all the same problems of Redhat, although to be fair, I didn't have time to finish looking it over as I needed that hardware for some real work the next day (and installed Slackware for that).
I've been using Slackware since around 2.0 or so. At around 3.4 I acquired a used Sun Sparc 5, and there being no Slackware for it, I gave Redhat 5.1 a try and it seemed OK. I then put Redhat 5.2 on a few machines. As I was getting more and more extensive in making system changes to automate more administrative processes, Redhat eventually became more and more of a pain and 6.0 was my last Redhat. I moved back to Slackware at 4.0 about 1 week before 7.0 came out, but quickly switched to 7.0. I still have 3 machines running Slackware 3.4 so I guess I never really abandoned it. OTOH, there's still 1 running Redhat 5.2 and 1 running Redhat 6.0.
One thing that I disliked greatly about Redhat was the RPM system. While it did allow a nice quick install of a package I did not have before, it really screwed me over with dependency stuff. I frequently update stuff, and on occaision, I was trying to update something a lot of other stuff depended on, and could not because of the dependencies. I was doing the updates from original sources, not RPMs, so the dependencies had to be forcibly removed and the old package deleted for the time being. Then future packages could not install because the dependencies were now screwed up.
RPM basically came across to me as a lock-in feature. That means, once I start using it, I have to keep using it to get any benefit from it. That also means, I have to wait for updates to come out in RPM format before I can upgrade something if I want to keep my RPM DB consistent. I would really much prefer that the presence or absence of a package be predicated on whether the package actually is installed, not whether some DB entry says it must be. I really dislike it when a DB that claims things is out-of-sync with reality, and that is a problem I encountered with the Redhat Package Management system.
I also found problems in making changes to the RC scripts in Redhat. In order to make some daemon scripts work right, I had to modify some of the core functions because they were in the way. Then other stuff broke. It became a nightmare. OTOH, I wasn't entirely happy with the BSD traditional RC scripts that Slackware uses, either. About a month and a half ago, someone on IRC challeneged me with "So just write your own rc scripts, then". So I decided to do so. It was Slackware that served as the foundation to do that because Slackware is still the easiest to change things in the system. What I ended up with was a daemon-script based system in the sense of separate files for each daemon, but with everything in a single subdirectory in /etc without the symlinks. Now the entire setup of what scripts run in what order in what runlevels are easily listed all at once. And now I don't get cut off from the machine when I change run levels from a remote connection.
I'm not saying that Slackware should become like that. What I am saying is that Slackware makes a great foundation for any of us to try out our own ideas on how things should be, especially if you, like me, prefer keeping things uncomplicated. BTW, I've been running my new RC script scheme on a few machines now and it works like a charm. It looks like I'll eventually be converting everything over to it.
Keep up the good work Patrick, David, and all the other folks at Slackware!
Actually it is more likely the case that the best programmers tend to avoid, or leave, companies that place more emphasis on using lawyers as a tool of harassment.
Mirror, mirror, on the wall,
whose code is it I have today?
I wonder how they have the gall,
to want to take it all away.
Now that the code is my very own,
will they want next to come for me?
But if it is that I'm not alone,
how can they cause that to be?
If we spread that code far and wide,
using hyper links and chain.
maybe they will just decide
that in this is more cost than gain.
I'm an American, and it pisses me off to no end.
We need a law that says that court costs must be paid for by the plaintiff when seeking judgements in cases out of jurisdiction (e.g. a waste of court time that could be better spent locking real criminals up behind bars).
There was no indication in the ruling (although there appeared to be an assumption) that the same person listed as the contact also offered it for auction.
This could well have been a case where one person registered it with the intent of speculating and/or squatting, or maybe even had a legitimate intent to use that fell through, but entered an incorrect contact handle when registering it (and may not have noticed). The person who did get listed could not really legally act as the owner since he was not the registrant. By his refusal to transfer the domain, he avoided liability to the registrant, who may have had a legitimate use for the domain (the contact may not have known the registrant was offering it for auction).
It is very common for people to be entering new registrations, and while trying to enter their own contact handle, goof and transpose a digit or letter and accidentally "give" it to someone else.
I've had to fix things like this for customers a few times already. It happens and it's not uncommon.
If such a thing does happen to a domain, correct entry of working servers can cause the web site to actually work despite the wrong contact. Further, the real "owner" may be totally unaware the error even exists. Since his name is not on it, it could be hard to track him down.
Imagine yourself in a position where someone registers a domain and accidentally makes YOU the contact for it. Then when someone who has a trademark approaches you and says they want the domain, you just sign the papers and hand it over to them. Then it turns out the registrant also had a trademark or other legitimate use, and now sues YOU for damages.
This is probably not much different that laws on lost property. If you give the property to someone else, you could be accused of transferring property that is not yours. If you sign your name to papers to do the transfer (as would be the case for a domain) then the situation is even worse.
One of the problems with certification is that employers tend to NOT want to pay you any (or much) more once you do get certified (assuming they hired you before being certified, and wanted you to get certified afterwards). Perhaps this is because employers (managers) themselves don't really see any value to the certification in the sense of valuing you as an employee, though they often do see the value in terms of customer relations. What this means is that to am employer, certification of an employee is something to tally up and brag about to a client or potential client, and is quickly forgotten about when your next salary review comes up. I see more demand for certification in body shops (e.g. consulting firms), whether that be Microsoft, Sun, Oracle, Baan, PeopleSoft, Lotus, Cisco or Redhat. I see less of that demand when the employer is not in the business of peddling warm bodies to other businesses.
Consider this. If the consulting firm is presenting themselves to a client, who's reputation are they trying to present and bolster when they do this? Certainly not the reputation of the individual who will end up coming out there for are short time to work. There are some exceptions, but that's generally when the person being presented has something even better than a certification, such as a Ph.D., or they were on the development team of the product they are consulting for.
Pick one of the better known Linux developers whose name you know. Now imagine some Linux consulting business manages to get them on staff or as a partner. Of course when they present to a potential client that needs such a person, they will point the praises directly to them. The certification, if they even have one, probably won't even be mentioned (although they surely won't forget to add it to the tally sheet for other clients). For the rest of us in other situations, we're just numbers on a tally sheet that gets presented to the clients as part of the reputation building of the company itself.
This is the unfortunate of how business does work. There isn't much else that can be done when company A wants to build its reputation to company B in order to get company B's business. As evil as many of us want to think of certification (and it probably got that reputation from the way a couple of other companies were handing them out) it is about the only thing business has to go on when you're looking at the third party consulting market.
What Redhat is doing, by charging much higher fees, and making the test much tougher, is probably an effort to avoid dilution of the certification value. I can tell you this. If I was hiring an NT administrator, and two candidates both had one year experience working with NT in an administrative capacity, and one had an MCSE while the other had a CCIE, I'd hire the CCIE in a heartbeat and sleep well that night. Cisco has done well to make sure their certification program represents the value of the people that earn it. Maybe Redhat is actually trying to do just that, too.
Because the bad guys have 'em, and use 'em, the good guys have to have 'em, too. The trouble is, if you pull yours out and use it first, you're now a bad guy.
I did this in 1996 when I was building a shopping cart for collecting tax forms. It didn't work very well because it messed up DNS, foobarred my test proxy server, and confused the firewall. I wish I had some evidence of the prior art, but it was actually a stupid idea and would have prevented my site from achieving the performance levels it did, so I did the thing that seemed right at the time and abandoned it.
I'll say "Thank you" when there is something to give thanks about.
Lost of people and lots of businesses can put together several machines and run a few different Linux distros and a few BSDs. Far fewer can make a true universal platform farm (the better term is "lab"). A company like VA Linux has the resources to not just to the corner cases, but also fill in all the gaps. If they are true to their word they will, and they won't have any doubts about it up front.
What makes you think that new TLDs would be complicated? They would simplify a lot of things.
Who needs those ICANN controlled root servers, anyway?
You can actually run your own root server. Then you have total control over what TLDs will be present and which registry supplies the zone data. All that is needed is for you know how the name servers to point to for the traditional and national TLDs, if you even want to carry them.
A couple years ago I created a concept I called Grass Roots Servers . The idea was that the root servers would really be run as described above. I came up with this idea because of the issue of deciding who would be the one to supply zone data for a new TLD. Since I didn't want political cronies or mega corporations making the decision for everyone, and I didn't want to be making that decision, either (as if I could), I figured the best place to decide was as close to each user as possible. One interesting thing about this is the fact that nothing has to be done by any sort of political or corporate power to enable it.
The difficulty in such a thing is that most people don't want to deal with the complexity of dealing with finding all the TLD name servers, and building the appropriate zone data file. That's where I came up with the web site Grass Roots Servers which would be a way to select the TLDs you want to have, or don't want to have, and have a zone file built for you. If the idea caught on, surely more tools would be created that just my first attempt, of which source can be downloaded if you want. Keep in mind I did this a couple years ago and have not updated it. The data is kind of old, but some of it may work.
So, do you want them to control your view of the domain name system, or do you want to control it yourself?
Actually, I'd love to buy from VA Linux, but I also want, if I stop building my own and buying pre-built machines, to get all my needs from one source. Unfortunately, VA Linux doesn't have enough of a product line to suit my needs, yet. I want something from VA Linux that competes with IndyBox's 1U servers.
There's already efforts to make some open source programs available on Solaris here. Make the commitment to at least a few platforms that VA Linux does not sell, so we know you are serious and that this is not just a scheme to market your hardware and that you actually intend to make this the thing you claim it to be. Also, will you commit to having SourceForge on early Itanium machines as soon as you can get them from Intel?
I'm sure there are a lot of issues you have to work with, security being the most critical. For example, what if the project requires root access (some programs need to be SUID root for users, and some are tools for system administration). I know it won't be easy. So get a few Sparc and Alpha boxes, put them behind a tight firewall which prevents people from getting out execpt via their own SSH tunnel, put BSD, Linux, and Solaris up as appropriate, and just let it go as a little "glass world" experiment so you can at least see what the issues are you'll have to deal with.
So, when will we be able to get both our domain names, as well as our SSL certificates, from slashdot?
If the drive heads warmed up less than the platters, the differential expansion due to thermal changes would surely distort the spacing and change the character of the way the heads ride over the platter airflow. A difference in the temperature between the air and heads could also be a source of potential problems. I have doubts they specifically cool the heads. But perhaps they do have coolant running through everything, or maybe the outer frame.
The heat sources would be the electronics (mostly underneath, but some are inside, such as the head pre-amps), the platter motor, and the voice coil. The better the bearings are, the lower the resistance to spin, and the less energy required to maintain RPM. But at higher RPM, the resistance increases by some formula I have long forgotten, so there will still me more energy needed, and thus more heat dissipated, to maintain RPM. Lighter platters would also help, but I'm not sure just to what degree this is once the drive has spun up. Head seeking needs to be faster and faster to meet our demands and expectations, too, and that means more energy in the voice coil to increase the acceleration.
So, they will be very hot! But will the heads specifically need to be cooled? I doubt it. And running coolant out to the heads would likely weight them down a whole lot.
At that speed, the noise will be a fault line rupturing 0.25 Hertz!
Let's get those puppies spinning in sync so we can slow down the spin of the earth and put more hours in a day!