"The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."

Throwing tents into dumpsters, without issuing a 'vacate or your property is forfeit' order seems like a clear violation to a non-lawyer.

Lawyers? Or have I simply missed something requiring the demonstrators to disperse?

What about a head mounted display or virtual reality goggles? These would allow a huge image to be formed, without the need for a bulky display. If you want to DIY, such a beast could probably be built with an ipod/kindle/... and a few lenses (from binoculars or a View-Master?)

Getting really funky, there also seem to be people experimenting with drawing images directly on the retina of Macular Degeneration patients. Not recommended for DIY!

No new code (except in the rare case where you are writing a tool to migrate stuff out of the VirtualStore into a new unprivileged user data directory) should reference the VirtualStore. That was created because ignorant devs couldn't wrap their heads around ACLs and didn't listen when MS told them that there's things out there that aren't admins.

This will absolutely not make its way downstream into an existing RHEL release. Maybe future releases.

I agree the wow64 fs and registry direction is confusing as hell. With the benefit of hindsight, I suspect they would have designed that differently (I will just assume it was fundamentally possible, if a bit more work in the short term.)

c:\winnt vs c:\windows vs c:\win vs e:\foo are all theoretically valid windows directories, though. That's why windows has an API for finding the Windows directory.

Red Hat jumped the shark in 1997. Once you go slack, you never look back. You do continue to look forward, though.

While I imagine there are liekly cases where that statement about performance is true, I have generally not seen a performance boon from building 32-bits on 64-bit OSes.

I don't see why linux can't adapt to these boot protection schemes. Self-signed or vendor signed, as long as there's a way to import your key information, what's the issue? Frankly, code signing is a good thing, especially if you can perform it from the ground up.

I understand the anxiety, here, especially given that Sinofsky is not a popular figure and nobody wants to trust any initiative he backs. That having been said, MS (and partners) would be opening themselves up to swift antitrust action again if they were to engage in industrywide attempts to lock out OtherOS.

It's also important to recognize that there are deployments out there where people WOULD like systems where you CAN'T disable secure boot, and have really stringent protections around the boot process. It is unlikely that this type of configuration is one that would be used in the general consumer market; there's too much of a need for boot media and utility software. Imagine not being able to run memcheck or a recovery tool, ever.

Now, really, we need to hear this kind of language from BIOS, mobo, and ready-built systems manufacturers. Overall, an initiative like this is a good thing, but everybody needs to be on the same page. Not foaming at the mouth.

VHDL Cookbook is a good, though dated, intro.

Use ghdl to learn vhdl, without the need to have hardware, as it compiles VHDL to an executable. Icarus is similar, but for Verilog. gEDA has good tools, including the gtkwave waveform viewer. Combined, ghdl, Icarus and gtkwave are a pretty useful simulation suite. You can go a long way with simulation, since the normal design flow is to get the system 100% using simulation, then as a last step program the FPGA with maximal probability of it just working. As Bruce said, the actual partition, place and route tools are proprietary and specific to each FPGA vendor, and a google search will come up with a number of cheap FPGA boards.

Keep an eye on left field though. There is a convergence in progress between desktop CPU's, GPU's, parallel systems and FPGAs (which can be seen as an array of massively parallel simple processors). One day all I wrote may be obsolete and you will be able to program your FPGA in CUDA, or whatever results when mainstream programming figures out how to handle parallel systems properly.

VHDL Cookbook is a good, though dated, intro.

Use ghdl to learn vhdl, without the need to have hardware, as it compiles VHDL to an executable. Icarus is similar, but for Verilog. gEDA has good tools, including the gtkwave waveform viewer. Combined, ghdl, Icarus and gtkwave are a pretty useful simulation suite. You can go a long way with simulation, since the normal design flow is to get the system 100% using simulation, then as a last step program the FPGA with maximal probability of it just working. As Bruce said, the actual partition, place and route tools are proprietary and specific to each FPGA vendor, and a google search will come up with a number of cheap FPGA boards.

Keep an eye on left field though. There is a convergence in progress between desktop CPU's, GPU's, parallel systems and FPGAs (which can be seen as an array of massively parallel simple processors). One day all I wrote may be obsolete and you will be able to program your FPGA in CUDA, or whatever results when mainstream programming figures out how to handle parallel systems properly.

An alternative to a centralised repository is a mark up / semantic language that allows designs to be published on the 'net and automatically discovered and catalogued. Anyway, I'll keep an eye on openhardware.org and jump in when I feel I can contribute. Thanks for kicking this off.

Thanks. It's heartening to hear that experience shows that legal paranoia is not necessary.

>Yes, we definitely want to stimulate a new movement, and put both thought and experience into it.

I'm keen. Is the current action concentrated in any one spot, or distributed around the net?

My gut feeling is that given the activity of the last couple of years the "new movement" already exists. If what already exists was focused, documented and disseminated, there would be a substantial body of work. (IMO) What is needed is a distribution mechanism/platform: an opencollector on sterioids; a Debian for hardware.

There's also the question of whether open hardware is a new movement or a progression of the free software movement, in which case we don't create a Debian for hardware, but extend Debian to include hardware.

Thanks for the response. I'll keep an eye on the wiki.

In the OHL, I don't understand the legal basis for section 4, "Manufacture and distribution of Products". What gives this section any force beyond a "gentleman's agreement" or a legal bluff, which is easily ignored? I can see that copyright is the legal basis for section 3, dealing with documentation, but don't see the same for section 4. Don't get me wrong, I want the OHL to be binding, but currently I don't see how it can be.