The BSD license isn't viral, don't get confused. It is the viral nature of the GPL that restricts how you can license your additions.
If you take and modify a piece of GPLed code (that you did not write in the first place), and you wish to distribute or sell the resulting source and/or binaries, you are required under the GPL to basically licence your additions under the same terms, including making your modifications available in source form. The only way around the requirement is if you contact all the authors that created the original work and get permission from all of them to operate on the source under a different license (that is, for the original authors to re-issue the same source to you under a different license). This is nearly impossible for very large GPLed projects but, of course, very easy for small projects since there are only a handful of original authors. Some projects require that submissions sign over their rights to the project to give the project the ability to change the license it is distributed under (I believe the GCC project does this, for example, and MySQL forked off a proprietary dist using the same method). Baring this permission you can only modify the code under the terms of the license.
If you take and modify a piece of BSD code you are NOT required under the BSD licence to put your additions under the same terms. You can do whatever you want with your derived work, including selling it without disclosing your modifications. All the BSD license does is prevent you from removing the BSD copyright and licensing lines from the source code, and requires you to identify in documentation that your code was derived from BSD. In particular, this means that you can add whatever conditions you like to the combined (derivative) work, as long as they are not contrary to the original BSD license. That is, you cannot remove the requirement that your documentation contain a copy of the BSD copyright notice and licence. But it certainly does not in any way require that that be the ONLY copyright notice and license pertaining to the derived work.
Any third party is welcome to take the original BSD code and do whatever they want to it under only the terms of the BSD license. But if they want to take your modified work they have to adhere to both the BSD license and your own.
Only an idiot would think otherwise. I swear, where these people get their ideas is beyond me.
It's that simple. Think of the BSD license simply as published pure science... that is the closest parallel to its intent.
Money tends to throw a wrench into the works of an OSS project. I have seen it happen time and time again. GPL or BSD, it doesn't matter. At first people think its great, then something happens and the money is no longer there and, poof, suddenly the project is no longer able to support itself because people had become dependant on the cash flow. Or the core group decides to commercialize it (how many dozens of projects has that happened with? So many...) and work simply stops on the OSS version of the project, or people start arguing over where the money should go and who controls it, or it gets commecialized and the company then goes bust, or numerous other things.
Having source code available is no guarentee of continuance. What matters is who is doing the actual work. I don't recall a single instance where a previously uninvolved third party has ever been able to successfully fork a large open source project after the original authors broke up or went commercial. Forking comes from within... it almost has to for it to have any chance of succeeding.
For Debian this means that the resolution to the problem must also come from within. Either elements within the existing core group must fork the project, or they must work to resolve the mess the money has caused and become a cohesive entity again. No third party is going to bail them out.
You can shove more data over fiber, by several orders of magnitude, given enough equipment at the end-points. Copper only has a few hundred megaherz worth of useable frequency spectrum and that coupled with the noise floor and signal to noise ratio (SNR) puts an upper limit on how much data you can push over it. You can't just pump in higher voltages to improve the SNR because even with variable-sized twisted pair you will get noise leaking into adjacent wires.
The issue with fiber is that getting the several orders of magnitude improvement in bandwidth requires increasingly expensive equipment at the end-points. This is fine for long-haul fiber but obviously not appropriate for a consumer end-point. Fiber gets multiplicative bandwidth improvements by transmitting light at different frequencies all over the same physical fiber optic cable. Specialized chips can pick-off the frequencies and split them into individual transceivers. A consumer end-point could decode one of those frequencies fairly cheaply, but not much more then that before the equipment becomes expensive. This is certainly viable... the head-end can transmit dozens of frequencies over the fiber and the distribution point on the pole can split it out to homes, or even just route it over shorter-haul copper in proximity to the home (which is probably a lot cheaper then running fiber all the way into a home).
In the last 20 years high capacity capacitors, called 'dime caps' have become widely available. These capacitors typically range from 2V to 30V and have capacities of up to several Farads. I started using them years ago instead of lithium batteries for static ram backup. The capacitors use a thin-film technology. One capacitor the size of five dimes stacked on top of each other could be 'unfolded' into an area the size of a tennis court.
So it is certainly possible to envision a capacitor-driven car, but it would be *VERY* expensive and probably very heavy using current technology. Apart from the construction issue, most of these capacitors also have limited current capabilities... the internal resistance goes up as the current goes up. Historically they have only been usable in low-current applications.
It's fun seeing AMD and Intel playing hopscotch, but the days of a simple cpu upgrade causing the masses to replace their machines whoesale are long since over, and Intel was just a tad too late to the game for their Duo to be able to steal back all the market share they lost to AMD. I don't know about the rest of you but fan noise hasn't been an issue for me since I upgraded to an AMD64 X2 based MB with its hardware fan control and started using heatpipe technology. I have three shuttle XPC cubes on my desktop right now and the room is still very quiet. I have no desire to 'upgrade'.. my machines are already overpowered and mostly idle, what do I care if Internet Explorer takes 0.05 seconds less time to pop up?
Intel is likely to make some inroads in the server market except... well, except unfortunately Core Duo doesn't scale as well once you go to quad cpu setups due to the memory bottleneck. So their only real claim to fame is power use. Power is extremely important in the long term, but I don't see anyone rushing to replace all their AMD boxes with core duo just for that when they know AMD will come up with a power-competitive design in fairly short order.
The real problem Intel has is their inability to compete with Hypertransport. AMD is already pushing hard to make it a defacto standard for chip interconnect. Intel is working on their own solutions to the problem, but they are not hitting on all cylinders yet.
If anything is going to drive machine replacement in today's market, it is going to be the new ultra-fast PCI bus technologies. PCI has needed an upgrade for a long, long time. Nothing else will have much of an impact. GiGE is already faster then most hard drives so there isn't going to be much of a consumer push for 10GiGE. Cpu's are already fast enough and machines are already quiet enough. We are a far cry from the old days where every new advance doubled the performance of the previous year's boxes. In today's world magazines proclaim victory and tell people to trash their old machines for barely a 10% improvement, but unless there is a huge improvement in video technology even game players have no real reason to do so any more. The connection to the video card is the only thing left for which significant improvements can drive machine replacement.
Forking a project is not a walk in the park, it takes a huge multi-year commitment in time and effort and it does not necessarily follow that the solution to a disagreement, even a huge disagreement, is to fork a project. It just so happens that I had all the pieces necessary to fork DragonFly (particularly the time available to do so and the ability to self-fund the effort). Theo I believe had similar time availability and the ability to obtain funding (stressful as it probably is at times) to support the effort. Probably one of the biggest reasons why FreeBSD has fragmented leadership now is a lack of time on the part of its leaders verses other life events.
Forking a project is NOT necessarily detrimental. In fact, I would consider it more an evolutionary inevitability. The plain fact of the matter is that most Open Source projects are a confluence of like minded individuals which is at best ephermal in nature. People age, people's interests change, people's life situations change, new people coming in have a different take on things... to assume that a project can keep the same face forever and that such evolutionary changes as a fork in the road is detrimental can only lead to one result: stagnation.
I wouldn't hold Linux up as a poster child, either. Linux is one of the most commercialized projects in existance compared to the BSDs. Just because the core is free doesn't mean the product is. Every time I turn around yet another GPL'd project is being commercialized by its developers, or using tag-ons to the license that require the author to sign over his copyright to the project. The GPL license no more protects against proprietization and commercialization then the BSD license. Nor does it protect against fragmentation... Linux is far more fragmented then all the BSDs put together, and that has seriously hurt its ability to compete against Microsoft. It's nice to day dream, I guess, but the reality is very different.
Randomness exists in nature all over the place. In fact, in every single atom, simply because we are not living in a world that is anywhere near a temperature of absolute zero. A johnson noise generator costs a few cents. In analog electronics, keeping randomness *OUT* is actually the harder problem.
Frankly, you don't need all that much true randomness to generate random numbers. You just need to be able to continuously seed a CSPNG from a random source, and not even at a very high rate. A few bits a second is plenty.
There shouldn't be any passworded accounts on a developer machine at all. It should be SSH access via public key only, period end of story. I stopped using remotely accepted passwords over a decade ago. Passwords are only accepted on the console.
Come on, folks. This is UNIX-101. Don't be stupid.
This stuff has existed for decades. I had one of these for my cellphone ten years ago. It works great, sounds like you are talking from a quiet room instead of a car whipping down the freeway, even when you ARE in a car whipping down the freeway.
It certainly isn't worth $200, though. We are talking about maybe $2 worth of materials here, probably even less.
This is all rather silly. Nobody who needs RAID performance uses software raid, especially the crappy software raid found in most MB chipsets. It's just plain stupid. I wouldn't trust that junk even if I didn't care about performance! Use a hardware raid solution like a 3ware card or something similar (in particular cards with battery backup capabilties) and wash your hands of the whole affair.
Boy, you sure have a foul mouth. I suggest washing it out with soap.
My comments stand. Start posting prices and lets see how your idea of an open standard stacks up the reality. Oh yah, and remember for every $1000 you spend on your interconnect, that's $1000 less you have to spend on cpus and programmers with a clue.
The reality is that there is only one *correct* way to do a fast interconnect, and that is to build it into the CPU itself. Oh wait, AMD intends to do just that! That's what I'm waiting for. A cheap built-in interconnect that doesn't cost an arm and a leg or eat 100 watts of power all by itself. All this other junk has a shelf life of maybe a few years at best (as does pretty much all networking gear, but the difference is that this stuff costs 10 times as much). It's a huge waste of time for all but the most extreme clustered applications for which there is no algorithmic solution to the latency issue (read: people like to throw hardware at badly written programs more often then they should).
The slashdot summary is wrong. If you read the actual article the author has it mostly correct except for one comment near the end.
Ethernet latency is about 100uS through a gigE switch, round-trip. A full-sized packet takes about 200uS (micro seconds), round-trip. Single-ended latency is about half of that.
There are proprietary technologies that have much faster interconnects, such as the infiniband technology described in the article. But the article also mentions the roadblock that a proprietary technology respresents over a widely-vendored standard. The plain fact of the matter is that ethernet is so ridiculously cheap these days it makes more sense to solve the latency issue in software, for example by designing a better cache coherency management model and by designing better clustered applications, then it does with expensive proprietary hardware.
There are plenty of ways to generate truely random numbers. Using Johnson noise or, even better, ANY radiation source, and doing a simple statistical calculation can trivially yield a stream of random 1's and 0's. The military has been using johnson noise sources since at least the 40's, in fact. A quantum two-slit setup could also be used, a quantum state changes, or tunneling, or a billion other things, to generate truely random numbers. Why use a Quasar that is observable by everyone with all of these isolatable sources available?
-Matt
Re:some other advantages
on
Sudo vs. Root
·
· Score: 1
Urm. Anybody who actually puts a password on the root account is already doing something stupid. In fact, anyone who allows remote shell logins to any account via passwords is really asking to be broken into. You basically should allow ssh access ONLY, and ONLY via a key pair, as a means of getting a shell prompt. In/etc/ssh/sshd_config (at least on BSD system), set 'PermitRootLogin without-password', set up the ~root/.ssh/authorized_keys file, allow only ssh access to all other accounts, restrict by IP or domain if appropriate, and you are done.
no telnet, no rlogin, no rsh. Limit ftp to read-only (and disallow root logins, which should already be the default), etc etc etc. Every single entry in your password file should have its password '*' (i.e. no password access allowed), period, including root.
To access the root account from other accounts set up ssh access individually from those accounts, restricted to localhost ssh logins only.
Alternatively, or in conjuction with the above, for small systems, simply leave root without a password (i.e.::), make sure that root logins via all services are disabled entirely (which is the default now for BSD systems), except from the console, and simply put the admin in the wheel group so he can 'su' to root, and you are done.
sudo is really easy to abuse. Just having it installed on your system represents a major security hole. I recommend not using it at all.
Well, I wouldn't call DragonFly revolutionary yet, but a lot of people don't understand that our ultimate goal is closer to the idea of the network as the computer rather then the computer in the network.
In otherwords, what we are gunning for is the ability to create widely distributed computing sets not only within a LAN environment, but within a WAN environment ('the internet') as well, and for these sets of resources to operate transparently and appear as a single machine to the user.
To make this work pretty much the entire kernel has to be rewritten to properly incorporate the cache coherency management required to actually be able to operate efficiently in such an environment, and you aren't going to see much differentiation until we complete that process. Part of the work involves a true separation of work, which means threading operations (such as the TCP protocol stack) without having to rely on mutexes and other serialization methods that would otherwise require SMP/NUMA architectures to be efficient. The heart of the problem, though, is filesystem-level cache coherency and cache management. If a workload is operating across a slow WAN link with 50ms of latency you simply cannot afford to have data managed via synchronous protocols. The individual sites have to be able to manage data sets in a fully cache coherent manner with the only synchronous communication occuring only when there is a conflict requiring resolution. That isn't an easy problem to solve.
I get 40 of these a day across half a dozen machines. They only try a small combination of trivial passwords for accounts like 'root' and 'test' and 'admin', and occassionally user names using the same user name as the password, etc. Really quite sad considering that most Linux and BSD installs disable passworded-root logins via ssh by default. My guess is that they are going after Windoz boxes which for some unfathomable reason still allow people to do stupid things with passwords.
I got annoyed enough that I wrote a little script to pull the data out of my logs in real time and add an entry to my firewall, but the attacks are harmless to any sysadmin with a clue.
I don't think it's a good idea to incorporate binary modules not buildable from openly availble source, but I'm not rabid about not using such modules when it makes something work that I need to make work. I have to use NDIS on my laptop to get the wireless working and frankly I'm a very happy guy because it works:-).
But that doesn't mean I have to like it! I think it's a mistake to try to cow-tow to vendors that clearly don't understand the value open source gives them (specifically, the fact that they don't have to support the drivers themselves). There are many reasons why vendors don't like to give out source. For one thing, chipsets often have a lot of bugs in them that the driver code has to work around and the vendors don't like to reveal the fact that those bugs exist. Another reason is that vendors are often paranoid about their code, even when it is substandard compared to other drivers that might be available as open-source (commercial entities invariably believe that their hired guns can code better then we can, and they are invariably proven wrong when such code occassionally sees the light of day).
The question is do we want to support the bozo vendors and just perpetuate the problem? Or do we want to focus on supporting vendors that do provide good information on their drivers (or at least don't go nuts when someone reverse engineers it)?
Another problem with binary-only modules is that, well, they might have bugs which you can't fix because you don't have the source. Or they might rely on API breakages that you would really like to rip out of your system. Or they might not work with a later rev of the chip in question even when the later rev is only an incremental improvement over the previous chip. Or they may not work with a particular configuration that you want to make work. Then you are stuck with a substandard driver that only works on older machines.
If I were to state a position it would be that the occassional exception might be necessary, but that it just isn't a good idea for the open-source community to rely on vendor-provided binary modules to make hardware work.
This brings up a far more important question, which is whether it is possible for an open-source 'trust' to be setup for the purposes of maintaining a driver whos source a vendor does not want to be released to the general public. That is, an entity which any open source programmer can join and through the signing of a simple non-invasive license then have access to the source for the purposes of making it work for that vendor's product line on open-source operating systems. The source would not be open to the public, but it would still be under the effective control of whatever open source programmers are interested in working on it. That is something I could live with and I think vendors could live with too if they took the time to think about it.
Well, I have to say the slashdot response to this release is a marked improvement over the response to the last release. Most people are actually getting the concepts right this time! Kudos!
There are a few things I will clarify about the release, in particular about our approach to SMP and the inevitable comparisons against, FreeBSD.
On the SMP front what we are doing is basically rearchitecting big chunks of the kernel to operate efficiently in both UP and SMP environments, to be NUMA-friendly, and to be as maintainable as possible. Rather then throw mutexes around existing code we are undertaking a huge effort to make as many of our subsystems as mutex-free as possible by localizing the subsystem's operation on a per-cpu basis. Most of the time that means rewriting them from scratch.
One example of this is our core Light Weight Kernel Thread scheduler (LWKT). Each cpu has its own indepenant LWKT scheduler which means that any given copy of the scheduler itself does not have to deal with or worry about contention between cpus. The code is very, very clean. If you think about it a bit you will realize that such a beast would work just as efficiently in an SMP environment as it would in a UP environment, and that is indeed one of our major goals.
A second example of this is our network protocol stack (whos major architect is Jeffrey Hsu). A TCP connection goes through a hash and is routed to a tcp protocol handling thread on a particular cpu. If you have N cpus then your TCP connections will generally be split about evenly between the cpus. Any given connection is localized to its cpu which means that all the work related to that connection occurs on a single cpu and thus does not have to worry about or deal with contention between cpus... and operates as efficiently on a UP system as on a SMP system. The L1/L2 cache effects are an important bonus as well but the winning ticket is the ability for the protocol threads to run in a tight loop without needing to obtain or release a single mutex, lock, or other synchronizing mechanism other then the occassional critical section (which is a cpu-localize synchronization mechanism against interrupts).
Another major goal is to make the code more maintainable... readable, understandable, etc, without any major gotchas to an unwary programmer, especially new programmers who are attracted to the project. This does not mean that FreeBSD is less stable, but I certainly believe that DragonFly's code base is a lot easier to maintain and a lot easier for new programmers to work with, with a much shorter ramp-up time then someone trying to dig into the FreeBSD codebase and far fewer new bugs introduced. I am taking a long-term view here.
The problem with building an SMP friendly algorithm which requires a lot of synchronization to avoid contention (the mutex model) is that it is really easy to make a mistake and introduce a hard-to-find bug, especially if you are just ramping up on the codebase. The solution is to use algorithms (aka cpu-localization algorithms) that avoid the contention in the first place, and that is what we are doing. Regardless of FreeBSD's current stability (and I believe that FreeBSD is now far more stable then it was a year ago), they had to go and stomp hundreds of bugs introduced by experienced programmers. That's a red flag in my book, one that I am making a major effort to avoid in the DragonFly codebase.
In less then two years of work (with very little destabilization of the kernel during that period, by the way), we are now within shouting distance of FreeBSD's and Linux's SMP parallelism. The only area where we are still significantly behind is in boot-time interrupt routing. This release is the last release where the Big Giant Lock is going to be in the critical path. We spent a lot of time isolating subsystems in order to reach this point, to be able to now take the last few steps and actually turn the Big Giant Lock *off* on a thread by thread basis. Not only tha
What bozo thought this might have anything to do with taxes? The google founders are filthy rich, they don't NEED a salary. Just building their company up will generate essentially tax-free equity far in excess of any salary they might have. And, frankly, whatever salary they might have, even if it were in the millions, would have no effect whatsoever on their taxes if they decide to e.g. exercise any of their options or sell stock. They would get hit by the alt-min tax either way.
I may not be Warren Buffet but I dare say I know more about this junk then most of the other people on this list.
No, the VM subsystem... that is, the concept of using stackable VM Objects, is going to stay in. I do want to implement a copy-on-write mechanism for pages owned by in-progress I/O to avoid stall situations that still exist in FreeBSD (despite Kirk's filesystem bitmap hacks, which only really fixed the worst of the stalls). There are also some kernel memory subsystem interactions with the VM system that need cleaning up to make things more MP friendly, and vm_map's and a few other areas need some algorithmic cleanups... but it's just cleaning up, not a rewrite. Generally I believe the VM Object based VM subsystem used in FreeBSD and DragonFly to be superior to the mechanisms used in other BSDs and in Linux.
Oh for heaven's sake. It's not *that* big a deal! It's there so all the new VFS work, which is virtually guarenteed to create some destabilization despite our best efforts (because we are literally ripping out and replacing the entire VFS interface), doesn't screw up people trying to use DragonFly as a production platform.
Wait a few months and there will really be some new cool things to brag about. The new VFS layering is going to allow us to implement a generic journaling interface (read: real time continuously streaming fs backups and other cool things).
Umm. Wind power does not take energy out of the atmosphere. Well, it does, but then it goes right back into the atmosphere as heat from system losses and appliances.
The only way to take energy out of the atmosphere is to convert it into RF/light and beam it up out into space on a clear night. I suppose you could bind atoms with it too, as long as what you are making isn't likely to be turned back into energy.
Keep in mind that the size of the JPEG file the camera produces depends a lot on (1) How well the camera implements the JPEG algorithm and (2) The amount of sensor noise. Little point-and-shoots have a lot more sensor noise then higher-end DSLR's and thus tend to produce much larger JPEG output files pixel-for-pixel. The Canon 10D series (including the 300D 'Digital Rebel') DSLRs have very good low-noise sensors and one of the best JPEG compressors in the business, with the highest quality JPEG mode producing 2-3 MByte JPEG output (6 Mpixel camera) and lower quality JPEG modes at full resolution produce much, much smaller files (
Your contrast and sharpness settings also have an effect. In-camera sharped photos generally produce larger JPEGs (because any noise is attenuated by the sharpening algorithm).
Mmmm. ok, I *HAVE* worked several weddings and I take a lot of shots, and 1 Gig CF cards work just fine thank you very much! In fact, I prefer using 1G or 2G cards over higher capacity microdrives just from a safety standpoint, if something were to go wrong I wouldn't lose the *entire* wedding.
Batteries are more of an issue, anyway, but even so it only takes a few seconds to changeout a CF card or a battery, so it just isn't worth the potential loss of data to use cards with ridiculously large capacities. You simply change the card out in an off moment, while you still have a hundred or so shots left so you aren't caught flat footed. No big deal.
Well, price and power is also a downside, especially if you run the boxes 24x7. All of our dual-cpu boxes (primarily DELL-2550's and some old VALinux boxes [running FreeBSD or DragonFly]) eat power like there was no tomorrow. Our single-cpu AMD64 boxes, on the otherhand, are twice as fast (as both cpus in the dell put together) and eat half the power (or less).
In nearly all cases you will be paying a premium for a SMP box over a UP box, so much so that if space is not an issue for you, and you have no special requirements (e.g. big honking database app), it will be more cost and maintainance effective to buy two single-cpu boxes then one dual-cpu box.
What this means is that I, at least, am turning off the SMP boxes in my machines room as fast as I can migrate them to new, faster, and far cheaper UP boxes.
On the flip side, though, both Intel and AMD are moving to dual core (and power-pc has had quad cores for a long time), so a SMP-efficient kernel design is as important as ever. Within the next 5 years I believe that all consumer cpus will be dual-core at a minimum.
Now all one needs to be able to do is seemlessly cluster them together, which is precisely one of our long-term goals! (seemless != the current hacks you see on Linux currently).
Slashdot Mirror
The BSD license isn't viral, don't get confused. It is the viral nature of the GPL that restricts how you can license your additions.
If you take and modify a piece of GPLed code (that you did not write in the first place), and you wish to distribute or sell the resulting source and/or binaries, you are required under the GPL to basically licence your additions under the same terms, including making your modifications available in source form. The only way around the requirement is if you contact all the authors that created the original work and get permission from all of them to operate on the source under a different license (that is, for the original authors to re-issue the same source to you under a different license). This is nearly impossible for very large GPLed projects but, of course, very easy for small projects since there are only a handful of original authors. Some projects require that submissions sign over their rights to the project to give the project the ability to change the license it is distributed under (I believe the GCC project does this, for example, and MySQL forked off a proprietary dist using the same method). Baring this permission you can only modify the code under the terms of the license.
If you take and modify a piece of BSD code you are NOT required under the BSD licence to put your additions under the same terms. You can do whatever you want with your derived work, including selling it without disclosing your modifications. All the BSD license does is prevent you from removing the BSD copyright and licensing lines from the source code, and requires you to identify in documentation that your code was derived from BSD. In particular, this means that you can add whatever conditions you like to the combined (derivative) work, as long as they are not contrary to the original BSD license. That is, you cannot remove the requirement that your documentation contain a copy of the BSD copyright notice and licence. But it certainly does not in any way require that that be the ONLY copyright notice and license pertaining to the derived work.
Any third party is welcome to take the original BSD code and do whatever they want to it under only the terms of the BSD license. But if they want to take your modified work they have to adhere to both the BSD license and your own.
Only an idiot would think otherwise. I swear, where these people get their ideas is beyond me.
It's that simple. Think of the BSD license simply as published pure science... that is the closest parallel to its intent.
-Matt
Money tends to throw a wrench into the works of an OSS project. I have seen it happen time and time again. GPL or BSD, it doesn't matter. At first people think its great, then something happens and the money is no longer there and, poof, suddenly the project is no longer able to support itself because people had become dependant on the cash flow. Or the core group decides to commercialize it (how many dozens of projects has that happened with? So many...) and work simply stops on the OSS version of the project, or people start arguing over where the money should go and who controls it, or it gets commecialized and the company then goes bust, or numerous other things.
Having source code available is no guarentee of continuance. What matters is who is doing the actual work. I don't recall a single instance where a previously uninvolved third party has ever been able to successfully fork a large open source project after the original authors broke up or went commercial. Forking comes from within... it almost has to for it to have any chance of succeeding.
For Debian this means that the resolution to the problem must also come from within. Either elements within the existing core group must fork the project, or they must work to resolve the mess the money has caused and become a cohesive entity again. No third party is going to bail them out.
Matthew Dillon
-Matt
You can shove more data over fiber, by several orders of magnitude, given enough equipment at the end-points. Copper only has a few hundred megaherz worth of useable frequency spectrum and that coupled with the noise floor and signal to noise ratio (SNR) puts an upper limit on how much data you can push over it. You can't just pump in higher voltages to improve the SNR because even with variable-sized twisted pair you will get noise leaking into adjacent wires.
The issue with fiber is that getting the several orders of magnitude improvement in bandwidth requires increasingly expensive equipment at the end-points. This is fine for long-haul fiber but obviously not appropriate for a consumer end-point. Fiber gets multiplicative bandwidth improvements by transmitting light at different frequencies all over the same physical fiber optic cable. Specialized chips can pick-off the frequencies and split them into individual transceivers. A consumer end-point could decode one of those frequencies fairly cheaply, but not much more then that before the equipment becomes expensive. This is certainly viable... the head-end can transmit dozens of frequencies over the fiber and the distribution point on the pole can split it out to homes, or even just route it over shorter-haul copper in proximity to the home (which is probably a lot cheaper then running fiber all the way into a home).
-MattSo it is certainly possible to envision a capacitor-driven car, but it would be *VERY* expensive and probably very heavy using current technology. Apart from the construction issue, most of these capacitors also have limited current capabilities... the internal resistance goes up as the current goes up. Historically they have only been usable in low-current applications.
-Matt
Intel is likely to make some inroads in the server market except... well, except unfortunately Core Duo doesn't scale as well once you go to quad cpu setups due to the memory bottleneck. So their only real claim to fame is power use. Power is extremely important in the long term, but I don't see anyone rushing to replace all their AMD boxes with core duo just for that when they know AMD will come up with a power-competitive design in fairly short order.
The real problem Intel has is their inability to compete with Hypertransport. AMD is already pushing hard to make it a defacto standard for chip interconnect. Intel is working on their own solutions to the problem, but they are not hitting on all cylinders yet.
If anything is going to drive machine replacement in today's market, it is going to be the new ultra-fast PCI bus technologies. PCI has needed an upgrade for a long, long time. Nothing else will have much of an impact. GiGE is already faster then most hard drives so there isn't going to be much of a consumer push for 10GiGE. Cpu's are already fast enough and machines are already quiet enough. We are a far cry from the old days where every new advance doubled the performance of the previous year's boxes. In today's world magazines proclaim victory and tell people to trash their old machines for barely a 10% improvement, but unless there is a huge improvement in video technology even game players have no real reason to do so any more. The connection to the video card is the only thing left for which significant improvements can drive machine replacement.
-Matt
Forking a project is not a walk in the park, it takes a huge multi-year commitment in time and effort and it does not necessarily follow that the solution to a disagreement, even a huge disagreement, is to fork a project. It just so happens that I had all the pieces necessary to fork DragonFly (particularly the time available to do so and the ability to self-fund the effort). Theo I believe had similar time availability and the ability to obtain funding (stressful as it probably is at times) to support the effort. Probably one of the biggest reasons why FreeBSD has fragmented leadership now is a lack of time on the part of its leaders verses other life events.
Forking a project is NOT necessarily detrimental. In fact, I would consider it more an evolutionary inevitability. The plain fact of the matter is that most Open Source projects are a confluence of like minded individuals which is at best ephermal in nature. People age, people's interests change, people's life situations change, new people coming in have a different take on things... to assume that a project can keep the same face forever and that such evolutionary changes as a fork in the road is detrimental can only lead to one result: stagnation.
I wouldn't hold Linux up as a poster child, either. Linux is one of the most commercialized projects in existance compared to the BSDs. Just because the core is free doesn't mean the product is. Every time I turn around yet another GPL'd project is being commercialized by its developers, or using tag-ons to the license that require the author to sign over his copyright to the project. The GPL license no more protects against proprietization and commercialization then the BSD license. Nor does it protect against fragmentation... Linux is far more fragmented then all the BSDs put together, and that has seriously hurt its ability to compete against Microsoft. It's nice to day dream, I guess, but the reality is very different.
-Matt (Dillon)
Randomness exists in nature all over the place. In fact, in every single atom, simply because we are not living in a world that is anywhere near a temperature of absolute zero. A johnson noise generator costs a few cents. In analog electronics, keeping randomness *OUT* is actually the harder problem.
Frankly, you don't need all that much true randomness to generate random numbers. You just need to be able to continuously seed a CSPNG from a random source, and not even at a very high rate. A few bits a second is plenty.
Move along,
-Matt
There shouldn't be any passworded accounts on a developer machine at all. It should be SSH access via public key only, period end of story. I stopped using remotely accepted passwords over a decade ago. Passwords are only accepted on the console.
Come on, folks. This is UNIX-101. Don't be stupid.
-Matt
This stuff has existed for decades. I had one of these for my cellphone ten years ago. It works great, sounds like you are talking from a quiet room instead of a car whipping down the freeway, even when you ARE in a car whipping down the freeway.
It certainly isn't worth $200, though. We are talking about maybe $2 worth of materials here, probably even less.
-Matt
This is all rather silly. Nobody who needs RAID performance uses software raid, especially the crappy software raid found in most MB chipsets. It's just plain stupid. I wouldn't trust that junk even if I didn't care about performance! Use a hardware raid solution like a 3ware card or something similar (in particular cards with battery backup capabilties) and wash your hands of the whole affair.
-Matt
Boy, you sure have a foul mouth. I suggest washing it out with soap.
My comments stand. Start posting prices and lets see how your idea of an open standard stacks up the reality. Oh yah, and remember for every $1000 you spend on your interconnect, that's $1000 less you have to spend on cpus and programmers with a clue.
The reality is that there is only one *correct* way to do a fast interconnect, and that is to build it into the CPU itself. Oh wait, AMD intends to do just that! That's what I'm waiting for. A cheap built-in interconnect that doesn't cost an arm and a leg or eat 100 watts of power all by itself. All this other junk has a shelf life of maybe a few years at best (as does pretty much all networking gear, but the difference is that this stuff costs 10 times as much). It's a huge waste of time for all but the most extreme clustered applications for which there is no algorithmic solution to the latency issue (read: people like to throw hardware at badly written programs more often then they should).
-Matt
The slashdot summary is wrong. If you read the actual article the author has it mostly correct except for one comment near the end.
Ethernet latency is about 100uS through a gigE switch, round-trip. A full-sized packet takes about 200uS (micro seconds), round-trip. Single-ended latency is about half of that.
There are proprietary technologies that have much faster interconnects, such as the infiniband technology described in the article. But the article also mentions the roadblock that a proprietary technology respresents over a widely-vendored standard. The plain fact of the matter is that ethernet is so ridiculously cheap these days it makes more sense to solve the latency issue in software, for example by designing a better cache coherency management model and by designing better clustered applications, then it does with expensive proprietary hardware.
-Matt
There are plenty of ways to generate truely random numbers.
Using Johnson noise or, even better, ANY radiation source, and doing a simple statistical calculation can trivially yield a stream of random 1's and 0's. The military has been using johnson noise sources since at least the 40's, in fact. A quantum two-slit setup could also be used, a quantum state changes, or tunneling, or a billion other things, to generate truely random numbers. Why use a Quasar that is observable by everyone with all of these isolatable sources available?
-Matt
Urm. Anybody who actually puts a password on the root account is already doing something stupid. In fact, anyone who allows remote shell logins to any account via passwords is really asking to be broken into. You basically should allow ssh access ONLY, and ONLY via a key pair, as a means of getting a shell prompt. In /etc/ssh/sshd_config (at least on BSD system), set 'PermitRootLogin without-password', set up the ~root/.ssh/authorized_keys file, allow only ssh access to all other accounts, restrict by IP or domain if appropriate, and you are done.
::), make sure that root logins via all services are disabled entirely (which is the default now for BSD systems), except from the console, and simply put the admin in the wheel group so he can 'su' to root, and you are done.
no telnet, no rlogin, no rsh. Limit ftp to read-only (and disallow root logins, which should already be the default), etc etc etc. Every single entry in your password file should have its password '*' (i.e. no password access allowed), period, including root.
To access the root account from other accounts set up ssh access individually from those accounts, restricted to localhost ssh logins only.
Alternatively, or in conjuction with the above, for small systems, simply leave root without a password (i.e.
sudo is really easy to abuse. Just having it installed on your system represents a major security hole. I recommend not using it at all.
-Matt
Well, I wouldn't call DragonFly revolutionary yet, but a lot of people don't understand that our ultimate goal is closer to the idea of the network as the computer rather then the computer in the network.
In otherwords, what we are gunning for is the ability to create widely distributed computing sets not only within a LAN environment, but within a WAN environment ('the internet') as well, and for these sets of resources to operate transparently and appear as a single machine to the user.
To make this work pretty much the entire kernel has to be rewritten to properly incorporate the cache coherency management required to actually be able to operate efficiently in such an environment, and you aren't going to see much differentiation until we complete that process. Part of the work involves a true separation of work, which means threading operations (such as the TCP protocol stack) without having to rely on mutexes and other serialization methods that would otherwise require SMP/NUMA architectures to be efficient. The heart of the problem, though, is filesystem-level cache coherency and cache management. If a workload is operating across a slow WAN link with 50ms of latency you simply cannot afford to have data managed via synchronous protocols. The individual sites have to be able to manage data sets in a fully cache coherent manner with the only synchronous communication occuring only when there is a conflict requiring resolution. That isn't an easy problem to solve.
-Matt
I got annoyed enough that I wrote a little script to pull the data out of my logs in real time and add an entry to my firewall, but the attacks are harmless to any sysadmin with a clue.
-Matt
I don't think it's a good idea to incorporate binary modules not buildable from openly availble source, but I'm not rabid about not using such modules when it makes something work that I need to make work. I have to use NDIS on my laptop to get the wireless working and frankly I'm a very happy guy because it works :-).
But that doesn't mean I have to like it! I think it's a mistake to try to cow-tow to vendors that clearly don't understand the value open source gives them (specifically, the fact that they don't have to support the drivers themselves). There are many reasons why vendors don't like to give out source. For one thing, chipsets often have a lot of bugs in them that the driver code has to work around and the vendors don't like to reveal the fact that those bugs exist. Another reason is that vendors are often paranoid about their code, even when it is substandard compared to other drivers that might be available as open-source (commercial entities invariably believe that their hired guns can code better then we can, and they are invariably proven wrong when such code occassionally sees the light of day).
The question is do we want to support the bozo vendors and just perpetuate the problem? Or do we want to focus on supporting vendors that do provide good information on their drivers (or at least don't go nuts when someone reverse engineers it)?
Another problem with binary-only modules is that, well, they might have bugs which you can't fix because you don't have the source. Or they might rely on API breakages that you would really like to rip out of your system. Or they might not work with a later rev of the chip in question even when the later rev is only an incremental improvement over the previous chip. Or they may not work with a particular configuration that you want to make work. Then you are stuck with a substandard driver that only works on older machines.
If I were to state a position it would be that the occassional exception might be necessary, but that it just isn't a good idea for the open-source community to rely on vendor-provided binary modules to make hardware work.
This brings up a far more important question, which is whether it is possible for an open-source 'trust' to be setup for the purposes of maintaining a driver whos source a vendor does not want to be released to the general public. That is, an entity which any open source programmer can join and through the signing of a simple non-invasive license then have access to the source for the purposes of making it work for that vendor's product line on open-source operating systems. The source would not be open to the public, but it would still be under the effective control of whatever open source programmers are interested in working on it. That is something I could live with and I think vendors could live with too if they took the time to think about it.
-Matt
Well, I have to say the slashdot response to this release is a marked improvement over the response to the last release. Most people are actually getting the concepts right this time! Kudos!
There are a few things I will clarify about the release, in particular about our approach to SMP and the inevitable comparisons against, FreeBSD.
On the SMP front what we are doing is basically rearchitecting big chunks of the kernel to operate efficiently in both UP and SMP environments, to be NUMA-friendly, and to be as maintainable as possible. Rather then throw mutexes around existing code we are undertaking a huge effort to make as many of our subsystems as mutex-free as possible by localizing the subsystem's operation on a per-cpu basis. Most of the time that means rewriting them from scratch.
One example of this is our core Light Weight Kernel Thread scheduler (LWKT). Each cpu has its own indepenant LWKT scheduler which means that any given copy of the scheduler itself does not have to deal with or worry about contention between cpus. The code is very, very clean. If you think about it a bit you will realize that such a beast would work just as efficiently in an SMP environment as it would in a UP environment, and that is indeed one of our major goals.
A second example of this is our network protocol stack (whos major architect is Jeffrey Hsu). A TCP connection goes through a hash and is routed to a tcp protocol handling thread on a particular cpu. If you have N cpus then your TCP connections will generally be split about evenly between the cpus. Any given connection is localized to its cpu which means that all the work related to that connection occurs on a single cpu and thus does not have to worry about or deal with contention between cpus... and operates as efficiently on a UP system as on a SMP system. The L1/L2 cache effects are an important bonus as well but the winning ticket is the ability for the protocol threads to run in a tight loop without needing to obtain or release a single mutex, lock, or other synchronizing mechanism other then the occassional critical section (which is a cpu-localize synchronization mechanism against interrupts).
Another major goal is to make the code more maintainable... readable, understandable, etc, without any major gotchas to an unwary programmer, especially new programmers who are attracted to the project. This does not mean that FreeBSD is less stable, but I certainly believe that DragonFly's code base is a lot easier to maintain and a lot easier for new programmers to work with, with a much shorter ramp-up time then someone trying to dig into the FreeBSD codebase and far fewer new bugs introduced. I am taking a long-term view here.
The problem with building an SMP friendly algorithm which requires a lot of synchronization to avoid contention (the mutex model) is that it is really easy to make a mistake and introduce a hard-to-find bug, especially if you are just ramping up on the codebase. The solution is to use algorithms (aka cpu-localization algorithms) that avoid the contention in the first place, and that is what we are doing. Regardless of FreeBSD's current stability (and I believe that FreeBSD is now far more stable then it was a year ago), they had to go and stomp hundreds of bugs introduced by experienced programmers. That's a red flag in my book, one that I am making a major effort to avoid in the DragonFly codebase.
In less then two years of work (with very little destabilization of the kernel during that period, by the way), we are now within shouting distance of FreeBSD's and Linux's SMP parallelism. The only area where we are still significantly behind is in boot-time interrupt routing. This release is the last release where the Big Giant Lock is going to be in the critical path. We spent a lot of time isolating subsystems in order to reach this point, to be able to now take the last few steps and actually turn the Big Giant Lock *off* on a thread by thread basis. Not only tha
I may not be Warren Buffet but I dare say I know more about this junk then most of the other people on this list.
-Matt
-Matt
Wait a few months and there will really be some new cool things to brag about. The new VFS layering is going to allow us to implement a generic journaling interface (read: real time continuously streaming fs backups and other cool things).
-Matt
The only way to take energy out of the atmosphere is to convert it into RF/light and beam it up out into space on a clear night. I suppose you could bind atoms with it too, as long as what you are making isn't likely to be turned back into energy.
-Matt
Keep in mind that the size of the JPEG file the camera produces depends a lot on (1) How well the camera implements the JPEG algorithm and (2) The amount of sensor noise. Little point-and-shoots have a lot more sensor noise then higher-end DSLR's and thus tend to produce much larger JPEG output files pixel-for-pixel. The Canon 10D series (including the 300D 'Digital Rebel') DSLRs have very good low-noise sensors and one of the best JPEG compressors in the business, with the highest quality JPEG mode producing 2-3 MByte JPEG output (6 Mpixel camera) and lower quality JPEG modes at full resolution produce much, much smaller files ( Your contrast and sharpness settings also have an effect. In-camera sharped photos generally produce larger JPEGs (because any noise is attenuated by the sharpening algorithm).
Batteries are more of an issue, anyway, but even so it only takes a few seconds to changeout a CF card or a battery, so it just isn't worth the potential loss of data to use cards with ridiculously large capacities. You simply change the card out in an off moment, while you still have a hundred or so shots left so you aren't caught flat footed. No big deal.
-Matt
In nearly all cases you will be paying a premium for a SMP box over a UP box, so much so that if space is not an issue for you, and you have no special requirements (e.g. big honking database app), it will be more cost and maintainance effective to buy two single-cpu boxes then one dual-cpu box.
What this means is that I, at least, am turning off the SMP boxes in my machines room as fast as I can migrate them to new, faster, and far cheaper UP boxes.
On the flip side, though, both Intel and AMD are moving to dual core (and power-pc has had quad cores for a long time), so a SMP-efficient kernel design is as important as ever. Within the next 5 years I believe that all consumer cpus will be dual-core at a minimum.
Now all one needs to be able to do is seemlessly cluster them together, which is precisely one of our long-term goals! (seemless != the current hacks you see on Linux currently).
-Matt