So, once its carrying your cargo along the path and begins to slide down a slope all the tracks will turn in unison to help carry it down the hill to its doom. They won't think anything is wrong because everyone will be pulling in the same direction.
if you can't solder using just the flux that's inside the solder wire, you should do a quick Soldering-101 course before you try hacking something...
Not that I RTFA, but try doing SMT with just the flux in your solder.. not gonna work.
A true hacker is beyond such dogmatic attitudes; (s)he uses the tools needed to get the job done. If flux is what's needed to get a good solder connection, then (s)he'll use flux.
I am not sure that photons 'have' to have mass. I would indeed suspect that they are 'forbidden' from having mass, due to the fact that they are traveling at the speed of light.
Photons lack mass but (since they move at 1,0 c) they do have momentum. This is wat makes solar sails work.
Hey, maybe that's the answer: substitute momentum for mass in all gravity calculations and see if that makes it all work.
F.A.N. released a real-time raytraced demo at breakpoint back in 2003. It does no more than 10 fps on my lowly 1GHz P3, but I'm sure it runs quite smooth on a nice modern CPU (though I don't think it's multithreaded).
Because such controllers use a proprietary disk format. So when (not if) your controller breaks, you need to get a new one to be able to read your data. Whereas when using a free (libre) operating system and software raid, you'll always be able to get to your data.
Why do I care what the bitstream looks like if I can move my "free" HDL from platform to platform?
Because right now, the proprietary nature of bitstream formats is keeping such innovations as reconfigurable computing back. To have a truly reconfigurable computer, it must be able to generate a new FPGA configuration on-the-fly, and be able to dynamically reconfigure (part of) an FPGA too.
To make the average developer able to research various approaches to this, an open FPGA architecture needs to be available, of which every single part and feature is documented and understood. There's no such architecture yet.
Getting truly open PC-hardware out of this a merely a nice short-term goal.
Why do I care what the bitstream looks like if I can move my "free" HDL from platform to platform?
Just because Xilinx' and Altera's toolchains are gratis (for low-end devices) right now, that doesn't mean they'll be gratis in the future. Also, because of its closed-source nature, such software cannot be studied and improved upon by its user, making him/her forever dependent on the device maker.
Finally, the portability of HDL code is greatly exaggerated. Sure, simple stuff like asynchronous logic and flipflops usually are portable, but once you start using more specialised features of an FPGA (eg. blockrams or embedded multipliers), you'll find every device maker's toolchain has its own quirks regarding component inference. So in practice, a HDL design is pretty much locked to a few specific devices.
If it's the compiler that bothers you then work with Xilinx, Altera, etc to get access to the bitstream format.
I think that if we are willing to accept less efficiency at the start, we can get what we need from Open Source.
Also, providing a way to do manual place-and-route and saving the resulting component locations in a separate file could go a long way. Developers could then use the automatic P&R whilst developing (and just live with the speed hit) and layout (part of) their design manually when they're done with the logic itself.
An interesting thing about HDL code wrt. "real" software is that it doesn't get changed very often. Once a design is done, it's really done, and rarely gets altered. This makes manual layouting a very viable option. As a bonus, it allows end-users to recreate the FPGA image from source without having to wait for P&R.
(replying to myself is probably a bit of a faux-pas here, but I'll do it anyway)
An interesting project (sadly now discontinued) was MPGA: an FPGA in programmable logic. That's a very nice way to develop and test various techniques for implementing programmable logic devices. Probably a lot cheaper than having multiple mask iterations too.
Hm. There are two issues here and I'm a bit confused regarding which you mean.
Place-and-route for the logic to load into the device.
My impression is that Open Source does exist to do at least part of this job. I don't know how good it is.
I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance), but I'm not aware of similarly licensed P&R software targetting programmable logic. And even if it were to exist, because the problem is so very hard I don't think it's going to be any good. If a company is going to put in 25 or more man-years to write a piece of very specialist software, they're going to ask money for it, not release it under the GPL.
Xilinx has been working on their own synthesis/P&R software (which is gratis for their lower-end devices) for a couple of years now, but it is still being outperformed by moreexpensivesoftware.
We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million.
Please don't forget the software, as most intelligence for programmable logic is contained there. Developing a wafer for an FPGA is easy compared to writing synthesis/P&R software for it. Automatic place and route is a really hard problem.
I figure this is at least $2 Million to get done.
I'd double that, and allocate most of it to synthesis/P&R software. Although such software obviously needs to be free (libre), I think you really want to pay people to write it or it'll never become useable.
I don't have the hardware expertise to lead this, or I'd already be started. Any volunteers? I'm quite serious.
Apart from the sheer amount of work, I have to admit it does sound like fun. Although I only have experience in targetting FPGA's (I've written a couple of microprocessor cores as well as some I/O devices), not developing them myself.
What would end the argument, Bruce is open-source hardware.
I take it you mean as in programmable logic? That's not much of a solution either. You still need good documentation, as reverse-engineering VHDL/Verilog code is hard (speaking from experience here).
What's maybe interesting to note here is that most asian hardware manufacturers are rather open about their hardware documentation, notably ralink and realtek. Companies like intel and texas instruments still don't want to cooperate. Something to keep in mind when purchasing new hardware perhaps.
Hitler was just a guy. He was no more 'evil' than most people to begin with, but through cunning and manipulation he managed to gain unfettered power to do what he wanted. Over time, that power changed him, and his baser side emerged.
Sure, but that was all prior to his political career. Mein Kampf, published in 1925, already outlines his plans for world domination and the eradication of anyone even remotely of yewish ancestry. For the historically impaired among you: the nazi's came to power 8 years later, in 1933.
If it takes an entire developement cycle to simply improve the current version's bugs, I'd gladly accept and encourage that.
I don't think one mere development cycle is going to be enough. Code improvement is a continuous process. The Linux kernel programmers could (and should) learn a lot from how the OpenBSD team works.
I've written a Linux kernel driver in the 2.2 days, and at least back then the kernel source was rather messy (I've heard it's been much improved since then). One problem the Linux kernel has is that subsystems are almost continuously replaced with something new. The old subsystem code is then allowed to rot. Back in the 2.2 days my problem was to find the appropriate way to handle locking, whereas nowadays the problem area is probably the VM.
What would really help the code quality of the Linux kernel is to start refactoring subsystem code and throwing out the old stuff that oughtn't be used anymore. Less code means less space to hide bugs in.
Slashdot Mirror
Yeah, totally unlike humans!
Er, wait...
As many as it wants.
You must be new here...
Er...
If you read that article you'll see that they use solder paste, which is essentially flux with a bit of solder mixed in.
Not that I RTFA, but try doing SMT with just the flux in your solder.. not gonna work.
A true hacker is beyond such dogmatic attitudes; (s)he uses the tools needed to get the job done. If flux is what's needed to get a good solder connection, then (s)he'll use flux.
Photons lack mass but (since they move at 1,0 c) they do have momentum. This is wat makes solar sails work.
Hey, maybe that's the answer: substitute momentum for mass in all gravity calculations and see if that makes it all work.
Translation for those who don't speak German: This post is hereby confiscated. Report to the nearest Gestapo office immediately.
Oh hey, only now I notice.. they've been at it since (at least) 2000.
F.A.N. released a real-time raytraced demo at breakpoint back in 2003. It does no more than 10 fps on my lowly 1GHz P3, but I'm sure it runs quite smooth on a nice modern CPU (though I don't think it's multithreaded).
From space?
Because such controllers use a proprietary disk format. So when (not if) your controller breaks, you need to get a new one to be able to read your data. Whereas when using a free (libre) operating system and software raid, you'll always be able to get to your data.
I think your plan relies on incorrect assumptions.
To make the average developer able to research various approaches to this, an open FPGA architecture needs to be available, of which every single part and feature is documented and understood. There's no such architecture yet.
Getting truly open PC-hardware out of this a merely a nice short-term goal.
Just because Xilinx' and Altera's toolchains are gratis (for low-end devices) right now, that doesn't mean they'll be gratis in the future. Also, because of its closed-source nature, such software cannot be studied and improved upon by its user, making him/her forever dependent on the device maker.
Finally, the portability of HDL code is greatly exaggerated. Sure, simple stuff like asynchronous logic and flipflops usually are portable, but once you start using more specialised features of an FPGA (eg. blockrams or embedded multipliers), you'll find every device maker's toolchain has its own quirks regarding component inference. So in practice, a HDL design is pretty much locked to a few specific devices.
No thanks, I don't do NDAs.
Also, providing a way to do manual place-and-route and saving the resulting component locations in a separate file could go a long way. Developers could then use the automatic P&R whilst developing (and just live with the speed hit) and layout (part of) their design manually when they're done with the logic itself.
An interesting thing about HDL code wrt. "real" software is that it doesn't get changed very often. Once a design is done, it's really done, and rarely gets altered. This makes manual layouting a very viable option. As a bonus, it allows end-users to recreate the FPGA image from source without having to wait for P&R.
(replying to myself is probably a bit of a faux-pas here, but I'll do it anyway)
An interesting project (sadly now discontinued) was MPGA: an FPGA in programmable logic. That's a very nice way to develop and test various techniques for implementing programmable logic devices. Probably a lot cheaper than having multiple mask iterations too.
Yes there is.
Place-and-route for the logic to load into the device.
I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance), but I'm not aware of similarly licensed P&R software targetting programmable logic. And even if it were to exist, because the problem is so very hard I don't think it's going to be any good. If a company is going to put in 25 or more man-years to write a piece of very specialist software, they're going to ask money for it, not release it under the GPL.
Xilinx has been working on their own synthesis/P&R software (which is gratis for their lower-end devices) for a couple of years now, but it is still being outperformed by more expensive software.
Please don't forget the software, as most intelligence for programmable logic is contained there. Developing a wafer for an FPGA is easy compared to writing synthesis/P&R software for it. Automatic place and route is a really hard problem.
I'd double that, and allocate most of it to synthesis/P&R software. Although such software obviously needs to be free (libre), I think you really want to pay people to write it or it'll never become useable.
Apart from the sheer amount of work, I have to admit it does sound like fun. Although I only have experience in targetting FPGA's (I've written a couple of microprocessor cores as well as some I/O devices), not developing them myself.
I take it you mean as in programmable logic? That's not much of a solution either. You still need good documentation, as reverse-engineering VHDL/Verilog code is hard (speaking from experience here).
What's maybe interesting to note here is that most asian hardware manufacturers are rather open about their hardware documentation, notably ralink and realtek. Companies like intel and texas instruments still don't want to cooperate. Something to keep in mind when purchasing new hardware perhaps.
That's not theft, it's not even copyright infringement. It's paraphrasing, and thus fair use (note: IANAL).
Let's not start parrotting the **AA.
That's actually some sort of bytecode. I've been hacking x86 assembly for 10 years now, and there's no way x86 has a "ldxb" instruction.
I don't think one mere development cycle is going to be enough. Code improvement is a continuous process. The Linux kernel programmers could (and should) learn a lot from how the OpenBSD team works.
I've written a Linux kernel driver in the 2.2 days, and at least back then the kernel source was rather messy (I've heard it's been much improved since then). One problem the Linux kernel has is that subsystems are almost continuously replaced with something new. The old subsystem code is then allowed to rot. Back in the 2.2 days my problem was to find the appropriate way to handle locking, whereas nowadays the problem area is probably the VM.
What would really help the code quality of the Linux kernel is to start refactoring subsystem code and throwing out the old stuff that oughtn't be used anymore. Less code means less space to hide bugs in.
Anyway, that's my E. 0,02.