There are three groups of license keys afaik -- retail, OEM and volume license. You can edit the ISO image of a Windows install CD -- change a couple of characters in a file -- and the resulting image will accept whatever style of key you like.
This site lists the values to use for each mode. I had success just changing the final three characters.
I used this method to install WinXP cleanly alongside Linux on my Toshiba laptop, using the legitimate license key stuck on the bottom. So all you need is a borrowed WinXP install CD of any sort at all (boxed, OEM, vol license), a Unix console, and a bit of RAM to load a 600MB 'text file', and you can legitimately install a clean copy of XP.
If anyone's wondering where the seemingly random '29 notes' figure comes from:
The fretting mechanism works on the first four frets, so each string can have five notes fretted on it (the four frets, and 'open', or no note fretted). Over six strings, this is 30 notes.
The fact that the G and B strings only have four semitones between them, as opposed to five for the other strings, means that there's an overlap of one note between those two strings: B can be played twice in that octave, reducing the number of distinct notes to 29.
There are many arguments for why this is a bad idea, but I think the most important one is that an absolute decision like this doesn't allow for corner cases.
A car is a mechanical thing. A driver can operate its controls and move it around at speed. It is not the job of the car to evaluate whether that would be a good idea or not.
A computer is a calculation device. It is supposed to perform logical and mathematical operations for the user at great speed. It is not the place of the computer to decide whether or not it should perform them.
Trying to make machines police their own use will never work.
It isn't needed in the vast majority of cases (most people can police their own alcohol consumption)
Its inability to spot corner cases results in unintended behaviour (after a few drinks, I'd be unable to drive someone to a hospital, or drive myself away from a gang of thugs)
The operation of the car now relies on another necessary condition that is highly dependent on the environment to work reliably (contaminants on hands, buildup on sensors, etc etc)
But above all, a machine is supposed to perform a task. It is the person using the machine that is supposed to decide whether it's a good idea or not.
Trying to delegate that descision to the machine is merely treating the symptom and ignoring the real problem. The past has shown us that this rarely, if ever, works.
is the amount of iPods that would sell because of this feature... worthwhile to finance development of an offical Vorbis plugin for iTunes/QuickTime plus a firmware upgrade for the iPods?
Personally, I believe it is worth it.
I've done a fair bit of programming with libvorbisfile and it has one of the best APIs of any library I've seen. Now I haven't looked much at Tremor (the integer / fixed-point implementation of libvorbis), but I assume its API is also quite nice.
If the iTunes codec model is worth its weight in.c files, then implementing Vorbis support should be easily doable in a solid day's work. Of course, there's testing and firmware integration and all those associated things as well... but I fail to see how this could be a huge undertaking.
Of course, it's not on the same level, but I've hacked support for a new format into a media player in an afternoon, and I'm certainly no guru.
In my experience, the only sure fire way to have a disk fail is to place any piece of important, but un-backed-up, work on it.
I completely agree.
I've seen quite a few dead disks in my time (fixing friends' and relatives' machines, etc), but the only time I've actually seen a disk die in the arse as I used it was when I had just copied 20G of my own data on to it.
The crap part was the data wasn't backed up.
To add insult to injury, the reason the data wasn't backed up was that I was using the drive as a temporary scratch drive while I was creating a RAID5 array for said data on my main disks.
Apples to oranges... He's talking a pentium-2 which is a glorfied Pentium MMX reneamed as 'pentium 2' and give some higher clockspeeds.
That's not the point. The 'pentium4' flag was an example. What I'm saying is that no matter what architecture you're on, the performance gain you get when you specify -march=foo as opposed to -march=i386 a) is negligible compared to varying system loads etc, and b) isn't big enough to justify massively redundant compiling that wastes a lot of time and energy.
the difference for a Pentium 4 user is going to be negligable. However, for users of slower processors, there is a hell of a lot of performance tweaking that can be done, that many distros completely ignore. a lot of code has been added to make programs run better and faster on MMX2 and MMX3 cpus like the Pentium-4 all that codebase, slows the program down greatly when running on a legacy MMX CPU.
This is all anecdotal, and greatly exaggerated. Do you have any benchmarks showing this quantitatively?
I do. Here's the results of compiling some code (it's a part of a project I'm working on, it does some HTML generation and is written in C). Base flags are -g -std=gnu99 -W -Wall -pedantic -I../include, and I added some others and benchmarked each change.
The times below are the result of running the code ten times. The machine is a dual-CPU Pentium MMX @ 166MHz * 2.
I ran each binary several times and used an average reading for each run. Note that the variation in each run was around 0.02 seconds either way, which is more than the difference between every run. So -O2 has a small but maybe noticeable impact, and the -march flags, in this case, have no noticeable effect.
Of course, they might have more of an impact with certain codebases than with others. But I hardly think the impact is going to increase by orders of magnitude.
realize there are other distros that specilize in older hardware too, but not everyone has a pentium 4 class cpu.
Again, it was an example. I'm not comparing my CPU to yours, or someone else's; I'm comparing any arbitrary CPU running binaries compiled for its revision (pentium-mmx, pentium4, whatever you like), compared to binaries compiled for generic i386.
binaries download much faster.. although nowhere near the 5 minutes you're talking about I've got 3 mbit cable service, and installing from the net-install disc took about 2 hrs all told.
Well that seems like an awfully long time. Last time I installed Debian the downloading took around 10 minutes, and apt-get spent about 5 minutes installing everything.
And don't confuse the time it took the whole OS to install with the time the package manager spent working. That's a completely different kettle of fish.
I have a PII-366 laptop that could not play movies until I installed Gentoo on it.
I don't understand how this myth continues to propogate. There are no end of benchmarks all over the net that show beyond any doubt that -march=pentium4, -fomit-frame-pointer and -omg-optimised don't have an appreciable impact on performance.
Sensible compiling employs the old faithful -O2 (or -Os to optimise for binary size if you must). This flag enables all optimisations that are considered stable and suitable for general use. Enabling all the 'leet' options has such a small effect (in the realm of 2%), and with some codebase / architecture combinations, it actually causes a slowdown.
The current operating state (system load, disk activity etc) has a far greater effect on the speed of execution of any application.
So, since -totally-go-fast and friends are gratuitous and have negligible effect on the overall speed of the system, the compiling can either be done once by the package maintainer, or ten thousand times by hackers all around the world. Why not let the maintainer do it, and save yourself the time and trouble? It's a much more efficient setup.
I used to run Gentoo myself, and quite liked parts of it (e.g. the nice clean init script setup). But seriously,
A significant emerge world: two hours
A significant apt-get update, apt-get upgrade: ~ 1 minute (the biggest I've ever seen took around 5)
There's not much of a decision to make as far as I'm concerned.
And don't even get me started on the people that insist on writing -O8 or something like it. A quick RTFM would reveal that options above -O3 don't actually have any impact anyway. In fact, the relevant code within gcc is something like
Well I'm not surprised you failed, seeing as there isn't really any such thing as a monitor driver under Linux at all.
All you have to do is find out the screen's legal frequency ranges, and pop them in your XFree (or Xorg) config as HorizSync and VertRefresh. If that makes you bare your teeth, then there are several GUI wrappers that will do this for you and have configs for literally hundreds of monitors (more than Windows has in its pesky database I'm sure;).
If you do it that way, then the fact that it's two lines of config instead of a driver doesn't even matter.
And there's no irritating initial setting up of refresh rates in each resolution, because XFree is incredibly intelligent and can (gasp) actually calculate the refresh rates from those frequency ranges above. Hot damn.
The worst offenders are (in no order of importance or difficulty): suspend (to disk or ram), accelerated 3d graphics, DVD playing, battery life monitoring (and general ACPI stuff), wireless networking, bluetooth, power-saving features (like CPU throttling) and making them extra buttons do things.
Sorry, but most of that is pretty misleading.
suspend (to disk or ram): OK, this is pretty unpolished still. Seems to work well for me though.
accelerated 3d graphics: tar -zxvf,./nvidia-installer. Done. Usually outperforms Windows. Can't comment on the ATI method.
DVD playing: Works better than Windows. apt-get install xine; pop in a DVD, and press the 'DVD' button.
battery life monitoring (and general ACPI stuff): Works out of the box with any distribution worth its weight in CD-Rs. If you roll your own kernels, just remember to compile it in. Then run gkrellm, the KDE or GNOME battery applets, or whatever you like.
wireless networking: Can be tricky, but usually works beautifully. Depends on the chipset. Still, room for improvement here.
bluetooth: Never used it.
power-saving features (like CPU throttling): apt-get install cpufreqd. Done. Works better than Windows.
making them extra buttons do things: apt-get install acpid. Done. Is actually configurable (you could set the power button to load Firefox and play a song if you wanted to).
I just wine'd/mnt/win2k/winnt/system32/progman.exe and got an ugly old Win3.1-esque program manager. It was useable as well.
Well, when I say useable, I mean it ran. Notice the distinction between that and 'usability'.
The only difference i could see between that and the 'real' Win 3.1 program manager i used in the old days were that Wine saw to it that the fonts were antialiased.;)
Although the sonic improvements of a single Signature power cable/power conditioner are transferred fully through conventional components power cords, use of an additional Magnan Signature power cord to connect to the component will improve the sound greatly.
The improvement achieved by a single Magnan power cable are directly additive with additional cables in series.
(emphasis mine)
Or, in other words, the more cables you daisy-chain, the better the effect?
When you build the bootloader it needs a copy of the firmware you want to use, and the kernel you want to boot Linux with. To get the firmware, you can just download the newest updater from Apple's website, use that other OS to update the iPod with it, and then just do a
dd if=/dev/sda1 of=./apple-firmware.
Then, the bootloader package has a tool to truncate that partition image (32MB iirc) to the actual bootloader. Done, and no windows trickery required, apart from the necessary iPod Updater run.
Actually now I think about it, the tool in the bootloader package is probably doing a similar job on the partition image as the resource hacker is in Windows. Ah well, always nicer to do it with dd;)
Attacking the RIAA seems more like a stunt than a real strategy, but hopefully the RIAA has the resources to invalidate this patent, if they do, then they will be doing the world of P2P a big favor.
This could potentially be an issue.
RIAA's overall motive is to make things as hard for P2P networks and their users as possible, in order to maximise profits. Altnet's motive could be to make a tidy sum from the RIAA, either through a payout or a settlement.
That in itself is just dodgy use of the law. But I think their motive could be a lot worse.
Altnet surely knows that the RIAA doesn't want to cut the P2P community any slack. But to win against Altnet in court, they would have to either show that they weren't infringing the patent (which seems unlikely) or invalidate it. The RIAA would surely rather an alternative arrangement with Altnet (i.e. a settlement), and in the process, Altnet's patent is proven in court.
This might have been the exact reason that Altnet chose the RIAA as their first target. Because with a patent so ridiculously broad and generic as this, they could pretty much go for anyone.
Slashdot Mirror
This is easiest under Unix of some sort:
This site lists the values to use for each mode. I had success just changing the final three characters.
I used this method to install WinXP cleanly alongside Linux on my Toshiba laptop, using the legitimate license key stuck on the bottom. So all you need is a borrowed WinXP install CD of any sort at all (boxed, OEM, vol license), a Unix console, and a bit of RAM to load a 600MB 'text file', and you can legitimately install a clean copy of XP.
Why not just outlaw killing? Solve the problem directly.
Oh, hang on.
rofl, that made my evening. Thanks for the laugh :)
I hear it's an estimate of the number of levels deep this thread is destined to grow.
*applauds*
Thankyou. That really needed to be said.
If anyone's wondering where the seemingly random '29 notes' figure comes from:
The fretting mechanism works on the first four frets, so each string can have five notes fretted on it (the four frets, and 'open', or no note fretted). Over six strings, this is 30 notes.
The fact that the G and B strings only have four semitones between them, as opposed to five for the other strings, means that there's an overlap of one note between those two strings: B can be played twice in that octave, reducing the number of distinct notes to 29.
In other news, Apple is set to release a new entry-level machine called the Mac Minnie.
A car is a mechanical thing. A driver can operate its controls and move it around at speed. It is not the job of the car to evaluate whether that would be a good idea or not.
A computer is a calculation device. It is supposed to perform logical and mathematical operations for the user at great speed. It is not the place of the computer to decide whether or not it should perform them.
Trying to make machines police their own use will never work.
- But above all, a machine is supposed to perform a task. It is the person using the machine that is supposed to decide whether it's a good idea or not.
Trying to delegate that descision to the machine is merely treating the symptom and ignoring the real problem. The past has shown us that this rarely, if ever, works.is the amount of iPods that would sell because of this feature ... worthwhile to finance development of an offical Vorbis plugin for iTunes/QuickTime plus a firmware upgrade for the iPods?
.c files, then implementing Vorbis support should be easily doable in a solid day's work. Of course, there's testing and firmware integration and all those associated things as well... but I fail to see how this could be a huge undertaking.
Personally, I believe it is worth it.
I've done a fair bit of programming with libvorbisfile and it has one of the best APIs of any library I've seen. Now I haven't looked much at Tremor (the integer / fixed-point implementation of libvorbis), but I assume its API is also quite nice.
If the iTunes codec model is worth its weight in
Of course, it's not on the same level, but I've hacked support for a new format into a media player in an afternoon, and I'm certainly no guru.
In my experience, the only sure fire way to have a disk fail is to place any piece of important, but un-backed-up, work on it.
I completely agree.
I've seen quite a few dead disks in my time (fixing friends' and relatives' machines, etc), but the only time I've actually seen a disk die in the arse as I used it was when I had just copied 20G of my own data on to it.
The crap part was the data wasn't backed up.
To add insult to injury, the reason the data wasn't backed up was that I was using the drive as a temporary scratch drive while I was creating a RAID5 array for said data on my main disks.
Thanks Murphy.
I do. Here's the results of compiling some code (it's a part of a project I'm working on, it does some HTML generation and is written in C). Base flags are -g -std=gnu99 -W -Wall -pedantic -I../include, and I added some others and benchmarked each change.
The times below are the result of running the code ten times. The machine is a dual-CPU Pentium MMX @ 166MHz * 2.
real / user / sys
none: 0.360s / 0.127s / 0.245s
-O2: 0.342s / 0.116s / 0.234s
-O2 -march=i386: 0.348s / 0.113s / 0.245s
-O2 -march=pentium-mmx: 0.355s / 0.113s / 0.248s
I ran each binary several times and used an average reading for each run. Note that the variation in each run was around 0.02 seconds either way, which is more than the difference between every run. So -O2 has a small but maybe noticeable impact, and the -march flags, in this case, have no noticeable effect.
Of course, they might have more of an impact with certain codebases than with others. But I hardly think the impact is going to increase by orders of magnitude.
Again, it was an example. I'm not comparing my CPU to yours, or someone else's; I'm comparing any arbitrary CPU running binaries compiled for its revision (pentium-mmx, pentium4, whatever you like), compared to binaries compiled for generic i386.
Well that seems like an awfully long time. Last time I installed Debian the downloading took around 10 minutes, and apt-get spent about 5 minutes installing everything.
And don't confuse the time it took the whole OS to install with the time the package manager spent working. That's a completely different kettle of fish.
I don't understand how this myth continues to propogate. There are no end of benchmarks all over the net that show beyond any doubt that -march=pentium4, -fomit-frame-pointer and -omg-optimised don't have an appreciable impact on performance.
Sensible compiling employs the old faithful -O2 (or -Os to optimise for binary size if you must). This flag enables all optimisations that are considered stable and suitable for general use. Enabling all the 'leet' options has such a small effect (in the realm of 2%), and with some codebase / architecture combinations, it actually causes a slowdown.
The current operating state (system load, disk activity etc) has a far greater effect on the speed of execution of any application.
So, since -totally-go-fast and friends are gratuitous and have negligible effect on the overall speed of the system, the compiling can either be done once by the package maintainer, or ten thousand times by hackers all around the world. Why not let the maintainer do it, and save yourself the time and trouble? It's a much more efficient setup.
I used to run Gentoo myself, and quite liked parts of it (e.g. the nice clean init script setup). But seriously,
- A significant emerge world: two hours
- A significant apt-get update, apt-get upgrade: ~ 1 minute (the biggest I've ever seen took around 5)
There's not much of a decision to make as far as I'm concerned.And don't even get me started on the people that insist on writing -O8 or something like it. A quick RTFM would reveal that options above -O3 don't actually have any impact anyway. In fact, the relevant code within gcc is something like
Can't argue with cold hard C.
it most likely incorporates code from XP/NT4 base
I would say it's less a matter of 'incorporates code from', and more a matter of 'consists primarily of'.
Well I'm not surprised you failed, seeing as there isn't really any such thing as a monitor driver under Linux at all.
;).
All you have to do is find out the screen's legal frequency ranges, and pop them in your XFree (or Xorg) config as HorizSync and VertRefresh. If that makes you bare your teeth, then there are several GUI wrappers that will do this for you and have configs for literally hundreds of monitors (more than Windows has in its pesky database I'm sure
If you do it that way, then the fact that it's two lines of config instead of a driver doesn't even matter.
And there's no irritating initial setting up of refresh rates in each resolution, because XFree is incredibly intelligent and can (gasp) actually calculate the refresh rates from those frequency ranges above. Hot damn.
The worst offenders are (in no order of importance or difficulty): suspend (to disk or ram), accelerated 3d graphics, DVD playing, battery life monitoring (and general ACPI stuff), wireless networking, bluetooth, power-saving features (like CPU throttling) and making them extra buttons do things.
./nvidia-installer. Done. Usually outperforms Windows. Can't comment on the ATI method.
Sorry, but most of that is pretty misleading.
suspend (to disk or ram): OK, this is pretty unpolished still. Seems to work well for me though.
accelerated 3d graphics: tar -zxvf,
DVD playing: Works better than Windows. apt-get install xine; pop in a DVD, and press the 'DVD' button.
battery life monitoring (and general ACPI stuff): Works out of the box with any distribution worth its weight in CD-Rs. If you roll your own kernels, just remember to compile it in. Then run gkrellm, the KDE or GNOME battery applets, or whatever you like.
wireless networking: Can be tricky, but usually works beautifully. Depends on the chipset. Still, room for improvement here.
bluetooth: Never used it.
power-saving features (like CPU throttling): apt-get install cpufreqd. Done. Works better than Windows.
making them extra buttons do things: apt-get install acpid. Done. Is actually configurable (you could set the power button to load Firefox and play a song if you wanted to).
Sorry mate, but that was a bit FUDdy.
Nice try, Russell. Take your band somewhere else.
It's there in Win2K as well.
/mnt/win2k/winnt/system32/progman.exe and got an ugly old Win3.1-esque program manager. It was useable as well.
;)
I just wine'd
Well, when I say useable, I mean it ran. Notice the distinction between that and 'usability'.
The only difference i could see between that and the 'real' Win 3.1 program manager i used in the old days were that Wine saw to it that the fonts were antialiased.
Or, in other words, the more cables you daisy-chain, the better the effect?
That's fradulent.
No need for the resource hacking tool.
;)
When you build the bootloader it needs a copy of the firmware you want to use, and the kernel you want to boot Linux with. To get the firmware, you can just download the newest updater from Apple's website, use that other OS to update the iPod with it, and then just do a
dd if=/dev/sda1 of=./apple-firmware.
Then, the bootloader package has a tool to truncate that partition image (32MB iirc) to the actual bootloader. Done, and no windows trickery required, apart from the necessary iPod Updater run.
Actually now I think about it, the tool in the bootloader package is probably doing a similar job on the partition image as the resource hacker is in Windows. Ah well, always nicer to do it with dd
For example, surely it wouldn't hurt Microsoft if they GPLed Windows 95
That's a good idea. The first step to healing a past hardship is to share the pain with others.
It's OK Bill, we're a forgiving bunch...
And more to the point, in my experience Intel chipsets are the single best supported chipsets under Linux.
Every Intel-based machine I've owned has operated beautifully under Linux.
Stop plugging your parent company's crap and tell me the state of the world!Hear hear.
RIAA's overall motive is to make things as hard for P2P networks and their users as possible, in order to maximise profits. Altnet's motive could be to make a tidy sum from the RIAA, either through a payout or a settlement.
That in itself is just dodgy use of the law. But I think their motive could be a lot worse.
Altnet surely knows that the RIAA doesn't want to cut the P2P community any slack. But to win against Altnet in court, they would have to either show that they weren't infringing the patent (which seems unlikely) or invalidate it. The RIAA would surely rather an alternative arrangement with Altnet (i.e. a settlement), and in the process, Altnet's patent is proven in court.
This might have been the exact reason that Altnet chose the RIAA as their first target. Because with a patent so ridiculously broad and generic as this, they could pretty much go for anyone.
I think it's a... remote... console? Yes? No.