Telecom companies do have some unusual pricing policies, but charging both sides of a connection aren't one of them. Both parties are receiving a service. Your payments to the telecom companies do not in any way represent payment for content figuratively or otherwise. What you're suggesting is some sort of 'cable company style scheme'. Yes the one where we pay cable companies, who in turn decide which programming to buy, and then give it to us--whether or not its quite what we want. I doubt many people wish to see this model extended to more markets. Content providers can and should choose to charge for access. Unfortunately people are being quite stupid about this. That much of the problem, though, does not belong on the shoulders of the telecom market.
Actually I am not. The margins are small. 'solar grade silicon' is also a bit of nonsense. Solar grade silicon is not more pure or rare than standard semiconductor grades. See: http://en.wikipedia.org/wiki/Silicon#Purification for more information. Basically the process requires high temperatures for long periods of time.
Ah. Solar. I couldn't help but notice a few years back that the city of los angeles had covered a parking lot by the Staple's Center with photovoltaics, and I often read about how it takes 20 years to recoup the cost of solar panels (less now with heavy government supports). The irony of this is that manufacturing solar cells consumes a good deal of electricity--and it turns out (I'm in the semiconductor industry) that this manufacturing cost is the bulk of the price. Meaning that not only does a solar cell take 20 yrs to pay itself back but it takes about that long to produce the electricity that it took to make!
Good news though: most fabs are built near sources of cheap electricity (hydroelectric).
But seriously, the best hope for solar is in large (and small) mirror arrays that allow the equivalent of many suns to be focused on a small (cheap) collector area ala 'Energy Innovations' the Idealab company.
But on another note. I don't think the author really understands what he is writing about. Some of his efficiency factor goals are definitely unrealisitic in the time-frame he describes. A charcoal to electricity process running at 50% efficiency is downright ridiculous.
Direct Carbon Fuel Cells are very expensive to make (require lots of electricity and other toxic chemicals) and have service lifetimes of only a few years depending on the purity of the fuel. Their efficiency is also low ~20%.
Having run both FreeBSD and Gentoo systems, I think you're missing the obvious reason for why people are more satisified with FreeBSD: it is precisely because it doesn't have: "slots and masking and multiple supported versions". Okay, wait. It does have multiple supported versions, although rarely.
The problem with USE flags is that every Gentoo build environment is __too__ unique. With FreeBSD, everyone is running, debugging, and fixing the same stuff. Consequently, most of the ports build & work together out of the box.
I've come to the conclusion that Gentoo is solving a problem that plagued the OSS community in the '90s.
Major 'server' software is usually known stable within a month of its release and is usually incorporated into FreeBSD ports with a corresponding lag--except when driven by security issues. The mentality is that everything in ports should 'work'. Instability and brokenness is frowned upon and not excused by allowing somethings to be classified as unstable. When differences of opinion exist about versions (e.g., firefox15 and firefox2) the name space is split, but this is only tolerated when people genuinely disagree as to which is better.
In the end: FreeBSD => less choice. Less choice => more consistency. More consistency => easier administration.
Obviously there can be too little choice at some extreme, but generally FreeBSD saves admin time by adopting some degree of simplicity and uniformity.
Actually, Gore won the popular vote in 2000. In addition, in case you missed it, Clinton had had 66%+ approval rating when he left office. Most political analysts now say that Gore's reluctance to embrace Clinton, coupled with how incredibly boring the man is, cost him the election. (Or, rather, made it as close as it was.) Oh, and not to mention the fact that it was the Supreme Court that handed Bush the win in 2000, stopping a recount that we now know would have resulted in a Gore win
Uh, say again. Almost all of the counting-standards give Bush Florida. Of the standard that would have given Gore the election (including overvotes), it happened to be the one criteria that Gore legal team repudiated in open court before the counting began.
SAS is not designed to be used by a SATA controller. If you wanted your cheapo SATA controller to work with SAS drives, it wouldn't be a cheapo controller. The difference between SAS and SATA is that SAS uses SCSI as its command language, which requires a whole different set of logic on the controller end.
Just so. Except one detail: This isn't the 1980s any more. Buying or designing the IP for a SCSI aware controller is simple&cheap. The fab costs are not likely to be more than for SATA. So, this isn't a cost issue per se.
The meat of it is the same market dynamics that lead to the widespread adoption of x86. SCSI might be better in the abstract but there is a non-SCSI market. IDE survived from its initial status as being cheaper. This happened because drive manufacturers mirrored the market. So by the time we get to SATA, SCSI is in the market as the expensive product and with the big cable. Yes they could have skipped SATA and gone straight for SAS but that suffered a perception of risk.
And it would mean (ultimately) that the high margins on SCSI drives would come down.
Mac users use it,
No they don't, they use Mach with a BSD api wrapper
Actually there is more BSD code than that. Mach provides the basic kernel infrastructure, but a few of the Mac device drivers are FreeBSD derived and large portions of the networking stack. Apple entirely replaced other sections of FreeBSD though, e.g., the USB stack.
and most of Linux is a cheap ripoff of it.
No, Linux is a school project based loosely off SunOS & Minix
Lets ignore the cheap ripoff part... and that Linux has its own historic origins. The evolution of Linux from 2.2->2.6 was definitely influenced by FreeBSD. e.g.,several algorithms from the FreeBSD vm were brought in to rescue linux from the vm problems of a few years ago. In many areas though Linux has caught upto and surpassed the FreeBSD kernel.
Actually it isn't the engineer who needs to buy two tools but rather the company who must decide ahead of time whether the factory is tooled for metric or customary units and then draft all the plans appropriately ahead of time.
But this situation is already changing. Many companies do things in metric with the intention of manufacturing in China. US based contract manufacturers are responding and starting to tool in metric.
Ergo... this is being solved by the market.
This says nothing though about why industries without the challenges of tooling precision need care.
And let me stake out a contrary position: metric is one of the most irrational measurement systems possible. There is something oddly redundant about creating names to distinguish quantities that are equally well designated by scientific notation or decimal-points alone. I have in mind the upheaval in semiconductors wherein we went from discussing 0.13um to 130nm. This is a pointless representational difference.
Conversely, scaling differences between different styles of units in the English system allow the notation to be fit to the physical reality. For every odd English unit there is a good historical explanation. e.g., a yard is about a stride, an inch is about the length of part of your thumb. These common sense approximations are quite useful--especially in cooking where the process is rough by nature. e.g., I don't own tablespoon and teaspoon measuring cups. I literally use a soup spoon and a tea spoon respectively.
And that is why the GPL is a gunpoint license. The irony here of course is that the fault clearly belongs to the authors of the start-stop daemon who failed to apprehend the meaning of the GPL license.
Just so. The anti-4 clause movement began with the FSF. Let me stake out the position that they are not entirely objective on this point. The imfamous clause 3 problem was and has always been a canard.
What's amazing is that people cite to the FSF propoganda and conclude they've prove their point.
Well here is the truth of the matter: Clause 3 relates particularly to advertising that discusses the features implemented by the code given in clause 3. What this means is you want to brag about softupdates and softupdates were covered by this imfamous third clause, you would have to say 'as implemented by Kirk...'
Anyways, this only applies to advertising with sufficient specificity to implicate particular code. Basically if you can trace a feature to 100s of contributors the clause is self-invalidating. No one contribution was responsible for the feature discussed in the advertising, therefore no mention is required.
The whole topic has been FUD for twenty years. That said, it has been such good FUD that people have actually taken extensive effort to purge the clause from the standard license. Only a few small files retain it today.
I think DragonflyBSD which is forked from FreeBSD 4.x is 4-clause free.
Hmm. I wouldn't believe that bit about it being a truss bridge and thus unusually hard to expand. All bridges are difficult to expand. In NJ, there is such a crossing. They just built more bridges. One direction of traffic uses the old bridge, the other direction uses the new bridge. Moreover, they built another much wider bridge for a parallel roadway.
The truth is that the cost of road construction pales in comparison to the economic losses of bad traffic. e.g., I lose 20-30% of my fuel efficiency in bad traffic. Not to mention all the time wasted.
A lot of places have traffic in a bad way because it became vogue starting in the 1970s to not expand the roadways. There developed this mythos that it was not possible to 'built your way out of congestion'--that roads themselves induced traffic. Ironically a principle whose truth is in fact due to years of delayed construction causing congestion and distorting the cost-benefit balance.
No. Its the KISS principle. Code complexity itself endangers security.
Rendering engines aren't rewritten frequently. Typically the code you have available for reuse supports many features you don't want: embedding, javascript, images (don't forget the GDI exploit). It is true that you can provide knobs to disable these dangerous features in the rendering engine. *BUT* have you ever been involved in real software verification efforts? Too many knobs means too little coverage.
Writing good tests is hard.
I have to assume that the DoD peformed some sort of balancing test: do the benefits of html exceed the risks?
People in general should ask themselves: do the benefits of pretty emails make up for the risk of having my computer rooted or leading to disclosure of personal information.
It is true, we could have both if enough people were willing to _pay_ lots of money for their rendering engine. It doesn't seem that is the case.
"Then the airplanes... Although no one has ever come out and directly stated why electronics on board a plane are forbidden during takeoff and landing. The rumours I've heard are that the generation of signals by those devices is strong enough to disrupt the plane's guidance systems thereby creating a risk of crashing. Not having been a pilot at any point, I can neither verify nor discredit this claim (but I'm sure some Slashdot reader who is a commercial airline pilot in his spare time will verify it for me)."
Don't ask the pilots. They know what they're told and what rumors and stories they pass around. Here are the 'facts': when a new plane undergoes flight testing they load it full of diagnostic equipment including many off-the-shelf unix workstations. This stuff is networked. It's no more shielded than office equipment. What is special about it is that it is *secured* and held fast with great care.
The planes do not mysteriously crash. On-board systems do not mysteriously malfunction.
It is true that modern CPUs, wireless technology operates near the IF (intermediate frequency) of some equipment. But the IF frequencies are not assigned by the FCC. It is the system integrator's responsibility to protect the device from interference on their chosen IF--usually with careful shielding and filtering on the inputs.
Turning off all electronic gizmos during take-off and landing is the airline/faa equivalent of "Warning: this cup contains hot liquids" on your coffee.
p.s. why does it cost $150,000 to go through university? Seems like rather a lot, surely with that kind of income there would be lots of colleges, academies and universities springing up and competing to reduce the costs.
Inflation. There are some serious defects in the standard techniques for measuring inflation: namely that it assumes trade balances, and other equilibrium features of the economy. The truth is that some goods are very domestic in nature and have been exhibiting inflation (housing, education, healthcare). Other goods--because of the trade imbalance--have their prices relatively pegged at lower values (i.e., anything that can be effected by overseas production).
The result is that people in the "domestic only" professions don't observe too much inflation, but the people in the "foreign influenced" markets do see quite a bit of inflation within the "domestic only" goods.
This isn't a problem with free trade. Its a problem with the braindead methodology used to compute inflation. The fact is that the Federal Reserve has been inflating the money stock at around 10% per annum. The ostensible theory behind this is that a growing economy needs more money. But in real-terms the economy is only growing a couple percent a year (real number unknowable because price inflation is not actually calculable). Moreover, the velocity of money is going up (higher velocity means that the same amount of money is used for more transactions).
Conclusion: 10% growth in money supply complete outstrips the actual growth of the economy => massive inflation is taking place.
We just don't see it in a broad measure because the Chinese government has been accumulating such a large surplus of our currency.
Actually I would rephrase that to be "most people are terrible at critical thinking"--by which I actually mean interpreting something for the purpose of criticizing it.
In my experience, people make and believe arguments that are rather poorly suited to the conclusion.
But at the same time, I think certain things mentioned in the article are overblown.
e.g., whether or not people click into the second page of search results. Personally I use google routinely to look-up websites that I already know. I'll recall something about the name of the site, but the DNS space is so crowded these days who can remember what sort of pseudo-english has been used to get a domain name. Enter google. Type in a few words--and wow, what I want appears in the top three. No need to search further.
An informal poll of my friends reveals they use google the same way.
I've also used google as a quick spell-checker before.
These experiences lead me to take a grain-of-salt with the 'using the first page only==stupidity' theory
Well. The trouble is actually OPEC. Production shares are set on the basis of reserve estimates. OPEC members have a strong incentive to inflate their reserve numbers so as to capture a larger share of the production.
When oil was primarily pumped by European and American oil companies (acting all over the world) they were public companies with substantial disclosure obligations: this meant detailed analysis and independent audits of how much oil they owned in the ground. After most oil production in the world was nationalized and run by State oil companies, the disclosures stopped.
So there is really very little public information about how much oil might be in the ground; well, we have public statements from the oil producing nations but little in the way of evidence. Amazingly, we don't even know how much oil is consumed. Wait, you're thinking: "I've seen barrels per day stats published". Sadly these numbers are discerned by counting tanker ships entering and leaving harbors.
For an introduction, I recommend reading "Twilight in the Desert". One caveat: this book proports to be technical; it isn't. Its mostly speculation and guess work. It is also rather redundant at times.
Most of the backlash against "Peak Oil" oil though _is_ deserved. Wells are said to run-dry when production becomes economically infeasible at current prices. There is still much oil in the ground. What has happened recently is that prices have risen faster than expected and suddenly reserve calculations have jumped up. Second, the question isn't so much about running out of oil as it is about limitations on how fast it can be pumped. If you pump a field too fast, you damage it. So the production rate is likely to peak+level off for quite some time before we run out of oil.
Obviously though is demand is so high that national oil companies "just pump harder" they will likely cause damage and experience a steep drop in production.
Oil is pumped harder by way of water injection. As a well ages, the oil pumped out becomes more and more contaminated with water. Actually 90% water, 10% oil isn't unusual. When this water fraction befores too big, production is abandoned (as too costly). Technology though is getting better and better about efficiently producing oil with an ever larger water cut.
Too much analysis has too many ceteris paribus assumptions.
This is untrue, and this whole story is dated--as of October 2.
See United States v. Arnold, 2006 U.S. Dist.
The central holding of this ruling is that the so called border-search exception to the 4th amendment (argued as implicit in the ability of the gov't to levy and enforce tariffs) cannot apply to personal effects such as notebook computer as the information it contains retains 4th amendment protection.
Consequently, searchs of your computer at the airport are illegal without a warrant.
Searches which do not access the information content--e.g., x-ray examination--are still allowed.
This case even had the "save the children" gateway to degrading the rights of the people--the defendent was found to have child pornography on his computer.
But he fails to discuss the one area where message passing makes a certain amount of sense. Even a single computer is beginning to look more like a distributed system today: SMP is becoming increasingly common. In these situations communication and coordination is often costly. The trouble with a monolithic kernel comes in precisely what it makes easy: sharing memory and data structures--the very sort of thing that if not done very carefully destroys SMP performance, e.g., by cache-line stumping.
Taking a hybrid approach where a kernel thread runs on each CPU begins to make a certain amount of sense. Message passing becomes an analog to the interprocessor IPI messaging and shared memory bus-locked instructions.
In other words: microkernel concepts (not implementation) become a discipline that helps you avoid doing seemingly simple things that are actually quite cycle-time expensive.
Naturally though it isn't right to call this new idea "microkernel" it isn't subsystem partitioning per se. It is definitely a hybrid idea.
Yes Hyrbid kernels can be more than marketing hype. On that point Linus is definitely just being an attention-whore by making a sweeping generalization.
No, this is going to happen extremely soon. One of the flaws of the softupdates approach was always in the code complexity. There is a definite feeling within the developer community that softupdates will be jettisoned soon, to catch the signs of this google for bad_dir panics or see http://www.freebsd.org/cgi/query-pr.cgi?pr=93942 or http://people.freebsd.org/~pho/baddir.html
You may also notice in the release engineering notes for 6.1 several references to UFS deadlocks. All of these were long latent softupdate bugs, mistakes in the dependency tracking, etc, etc. It was quite the rollcoaster as those fixes when in, often followed by several other "no still not right" commits.
Softupdate's days are numbered. The one clear advantage that UFS has these days is being extremely robust in the presence of disk errors. The same cannot be said of ReiserFS or XFS wherein the on-disk data-structures are so optimized the filesystem is prone to fall-over rapidly when on a degrading disk. Ultimately though this sliver of a benefit from UFS cannot warrant staying with something far outmoded by proven better methods (journaling) and large disks.
Incidentially, it is historically wrong to call "softupdates" a response to journaling. Softupdates predates wide-spread acceptance of journaling filesystems and in its heyday enjoyed better performance (no longer).
Your comment seems sort of jealous. Let me change your perspective. This is what Freedom is really about: the freedom to choose. A long time FreeBSD user myself (eight years now), I love the FreeBSD userland. Leaving room for some degree of experience bias--every linux distribution I've tried has felt messy. I also dislike LILO and GRUB. I prefer the rc system to init runlevels. But these are all personal opinions. The point, though, is that someone with much less experience might also like these same things.
If this work is considerd good, I wouldn't be surprised to see lots of merged back into FreeBSD proper. That said, FreeBSD has always been the sysadmin's OS. Configuring the window manager just isn't their core-competency.
As for your driver complaint: prove that it matters. I've never had trouble. As for "more software" it is a certainty that you have that backwards. FreeBSD's linux compat layer is very good. FreeBSD can run just about any linux binary with little to no futzing. Most software already compiles on BSD natively or will almost certainly do so within a linux chroot. On top of this you have all of the software that was originally developed for FreeBSD.
There is a growing consensus that Infiniband is effectively a dead-end. Last year it would have been a tough call between Infiniband, Ethernet, and other more proprietary interconnects. The market seems to be favoring the backward compatibility of Ethernet, and now that low latency Ethernet (~200ns) appears to be at hand there does not appear to be any reason to prefer the less general tecnologies (Myrinet, Infiniband, etc). My friends at Myrinet hint that they are looking to using the Myrinet protocol layer on top of Ethernet and essentially EOLing the Myrinet physical layer.
Myrinet was fabulously advanced ten years ago when it spun out of Caltech, but alas, the rest of the world has caught-up.
To be fair the manual says:/usr/local/pgsql/bin/initdb -D/usr/local/pgsql/data;/usr/local/pgsql/bin/postmaster -D/usr/local/pgsql/data >logfile 2>&1 &;/usr/local/pgsql/bin/createdb test;/usr/local/pgsql/bin/psql test;
What's the difference here? It uses the pgsql/bin wrappers. createdb does nothing more than execute the sql command "CREATE DATABASE" thus why one can simply connect to the database backend via psql and just type the CREATE DATABASE sql statement directly. I think this way has somewhat better error handling.
There are a bunch of configuration files in the pgsql directory (e.g. pg_hba.conf and postgresql.conf) once you know about these files... you can do just about anything.
Slashdot Mirror
!Stop!
I think you're flogging for the wrong reasons.
Telecom companies do have some unusual pricing policies, but charging both sides of a connection aren't one of them. Both parties are receiving a service. Your payments to the telecom companies do not in any way represent payment for content figuratively or otherwise. What you're suggesting is some sort of 'cable company style scheme'. Yes the one where we pay cable companies, who in turn decide which programming to buy, and then give it to us--whether or not its quite what we want. I doubt many people wish to see this model extended to more markets. Content providers can and should choose to charge for access. Unfortunately people are being quite stupid about this. That much of the problem, though, does not belong on the shoulders of the telecom market.
Actually I am not. The margins are small. 'solar grade silicon' is also a bit of nonsense. Solar grade silicon is not more pure or rare than standard semiconductor grades. See: http://en.wikipedia.org/wiki/Silicon#Purification for more information. Basically the process requires high temperatures for long periods of time.
Ah. Solar. I couldn't help but notice a few years back that the city of los angeles had covered a parking lot by the Staple's Center with photovoltaics, and I often read about how it takes 20 years to recoup the cost of solar panels (less now with heavy government supports). The irony of this is that manufacturing solar cells consumes a good deal of electricity--and it turns out (I'm in the semiconductor industry) that this manufacturing cost is the bulk of the price. Meaning that not only does a solar cell take 20 yrs to pay itself back but it takes about that long to produce the electricity that it took to make!
Good news though: most fabs are built near sources of cheap electricity (hydroelectric).
But seriously, the best hope for solar is in large (and small) mirror arrays that allow the equivalent of many suns to be focused on a small (cheap) collector area ala 'Energy Innovations' the Idealab company.
But on another note. I don't think the author really understands what he is writing about. Some of his efficiency factor goals are definitely unrealisitic in the time-frame he describes. A charcoal to electricity process running at 50% efficiency is downright ridiculous.
Direct Carbon Fuel Cells are very expensive to make (require lots of electricity and other toxic chemicals) and have service lifetimes of only a few years depending on the purity of the fuel. Their efficiency is also low ~20%.
Having run both FreeBSD and Gentoo systems, I think you're missing the obvious reason for why people are more satisified with FreeBSD: it is precisely because it doesn't have: "slots and masking and multiple supported versions". Okay, wait. It does have multiple supported versions, although rarely.
The problem with USE flags is that every Gentoo build environment is __too__ unique. With FreeBSD, everyone is running, debugging, and fixing the same stuff. Consequently, most of the ports build & work together out of the box.
I've come to the conclusion that Gentoo is solving a problem that plagued the OSS community in the '90s.
Major 'server' software is usually known stable within a month of its release and is usually incorporated into FreeBSD ports with a corresponding lag--except when driven by security issues. The mentality is that everything in ports should 'work'. Instability and brokenness is frowned upon and not excused by allowing somethings to be classified as unstable. When differences of opinion exist about versions (e.g., firefox15 and firefox2) the name space is split, but this is only tolerated when people genuinely disagree as to which is better.
In the end: FreeBSD => less choice. Less choice => more consistency. More consistency => easier administration.
Obviously there can be too little choice at some extreme, but generally FreeBSD saves admin time by adopting some degree of simplicity and uniformity.
Uh, say again. Almost all of the counting-standards give Bush Florida. Of the standard that would have given Gore the election (including overvotes), it happened to be the one criteria that Gore legal team repudiated in open court before the counting began.
Just so. Except one detail: This isn't the 1980s any more. Buying or designing the IP for a SCSI aware controller is simple&cheap. The fab costs are not likely to be more than for SATA. So, this isn't a cost issue per se.
The meat of it is the same market dynamics that lead to the widespread adoption of x86. SCSI might be better in the abstract but there is a non-SCSI market. IDE survived from its initial status as being cheaper. This happened because drive manufacturers mirrored the market. So by the time we get to SATA, SCSI is in the market as the expensive product and with the big cable. Yes they could have skipped SATA and gone straight for SAS but that suffered a perception of risk.
And it would mean (ultimately) that the high margins on SCSI drives would come down.
No they don't, they use Mach with a BSD api wrapper
Actually there is more BSD code than that. Mach provides the basic kernel infrastructure, but a few of the Mac device drivers are FreeBSD derived and large portions of the networking stack. Apple entirely replaced other sections of FreeBSD though, e.g., the USB stack.
and most of Linux is a cheap ripoff of it.
No, Linux is a school project based loosely off SunOS & Minix
Lets ignore the cheap ripoff part... and that Linux has its own historic origins. The evolution of Linux from 2.2->2.6 was definitely influenced by FreeBSD. e.g.,several algorithms from the FreeBSD vm were brought in to rescue linux from the vm problems of a few years ago. In many areas though Linux has caught upto and surpassed the FreeBSD kernel.
Actually it isn't the engineer who needs to buy two tools but rather the company who must decide ahead of time whether the factory is tooled for metric or customary units and then draft all the plans appropriately ahead of time.
But this situation is already changing. Many companies do things in metric with the intention of manufacturing in China. US based contract manufacturers are responding and starting to tool in metric.
Ergo... this is being solved by the market.
This says nothing though about why industries without the challenges of tooling precision need care.
And let me stake out a contrary position: metric is one of the most irrational measurement systems possible. There is something oddly redundant about creating names to distinguish quantities that are equally well designated by scientific notation or decimal-points alone. I have in mind the upheaval in semiconductors wherein we went from discussing 0.13um to 130nm. This is a pointless representational difference.
Conversely, scaling differences between different styles of units in the English system allow the notation to be fit to the physical reality. For every odd English unit there is a good historical explanation. e.g., a yard is about a stride, an inch is about the length of part of your thumb. These common sense approximations are quite useful--especially in cooking where the process is rough by nature. e.g., I don't own tablespoon and teaspoon measuring cups. I literally use a soup spoon and a tea spoon respectively.
And that is why the GPL is a gunpoint license. The irony here of course is that the fault clearly belongs to the authors of the start-stop daemon who failed to apprehend the meaning of the GPL license.
Just so. The anti-4 clause movement began with the FSF. Let me stake out the position that they are not entirely objective on this point. The imfamous clause 3 problem was and has always been a canard.
What's amazing is that people cite to the FSF propoganda and conclude they've prove their point.
Well here is the truth of the matter: Clause 3 relates particularly to advertising that discusses the features implemented by the code given in clause 3. What this means is you want to brag about softupdates and softupdates were covered by this imfamous third clause, you would have to say 'as implemented by Kirk...'
Anyways, this only applies to advertising with sufficient specificity to implicate particular code. Basically if you can trace a feature to 100s of contributors the clause is self-invalidating. No one contribution was responsible for the feature discussed in the advertising, therefore no mention is required.
The whole topic has been FUD for twenty years. That said, it has been such good FUD that people have actually taken extensive effort to purge the clause from the standard license. Only a few small files retain it today.
I think DragonflyBSD which is forked from FreeBSD 4.x is 4-clause free.
Hmm. I wouldn't believe that bit about it being a truss bridge and thus unusually hard to expand. All bridges are difficult to expand. In NJ, there is such a crossing. They just built more bridges. One direction of traffic uses the old bridge, the other direction uses the new bridge. Moreover, they built another much wider bridge for a parallel roadway.
The truth is that the cost of road construction pales in comparison to the economic losses of bad traffic. e.g., I lose 20-30% of my fuel efficiency in bad traffic. Not to mention all the time wasted.
A lot of places have traffic in a bad way because it became vogue starting in the 1970s to not expand the roadways. There developed this mythos that it was not possible to 'built your way out of congestion'--that roads themselves induced traffic. Ironically a principle whose truth is in fact due to years of delayed construction causing congestion and distorting the cost-benefit balance.
No. Its the KISS principle. Code complexity itself endangers security.
Rendering engines aren't rewritten frequently. Typically the code you have available for reuse supports many features you don't want: embedding, javascript, images (don't forget the GDI exploit). It is true that you can provide knobs to disable these dangerous features in the rendering engine. *BUT* have you ever been involved in real software verification efforts? Too many knobs means too little coverage.
Writing good tests is hard.
I have to assume that the DoD peformed some sort of balancing test: do the benefits of html exceed the risks?
People in general should ask themselves: do the benefits of pretty emails make up for the risk of having my computer rooted or leading to disclosure of personal information.
It is true, we could have both if enough people were willing to _pay_ lots of money for their rendering engine. It doesn't seem that is the case.
"Then the airplanes... Although no one has ever come out and directly stated why electronics on board a plane are forbidden during takeoff and landing. The rumours I've heard are that the generation of signals by those devices is strong enough to disrupt the plane's guidance systems thereby creating a risk of crashing. Not having been a pilot at any point, I can neither verify nor discredit this claim (but I'm sure some Slashdot reader who is a commercial airline pilot in his spare time will verify it for me)."
Don't ask the pilots. They know what they're told and what rumors and stories they pass around. Here are the 'facts': when a new plane undergoes flight testing they load it full of diagnostic equipment including many off-the-shelf unix workstations. This stuff is networked. It's no more shielded than office equipment. What is special about it is that it is *secured* and held fast with great care.
The planes do not mysteriously crash. On-board systems do not mysteriously malfunction.
It is true that modern CPUs, wireless technology operates near the IF (intermediate frequency) of some equipment. But the IF frequencies are not assigned by the FCC. It is the system integrator's responsibility to protect the device from interference on their chosen IF--usually with careful shielding and filtering on the inputs.
Turning off all electronic gizmos during take-off and landing is the airline/faa equivalent of "Warning: this cup contains hot liquids" on your coffee.
By the trace elements. Every reactor has a signature ratio of trace elements relating to how long its been in operation among other things.
That said, I'm not sure such an analysis could be performed with a corpse...
p.s. why does it cost $150,000 to go through university? Seems like rather a lot, surely with that kind of income there would be lots of colleges, academies and universities springing up and competing to reduce the costs.
Inflation. There are some serious defects in the standard techniques for measuring inflation: namely that it assumes trade balances, and other equilibrium features of the economy. The truth is that some goods are very domestic in nature and have been exhibiting inflation (housing, education, healthcare). Other goods--because of the trade imbalance--have their prices relatively pegged at lower values (i.e., anything that can be effected by overseas production).
The result is that people in the "domestic only" professions don't observe too much inflation, but the people in the "foreign influenced" markets do see quite a bit of inflation within the "domestic only" goods.
This isn't a problem with free trade. Its a problem with the braindead methodology used to compute inflation. The fact is that the Federal Reserve has been inflating the money stock at around 10% per annum. The ostensible theory behind this is that a growing economy needs more money. But in real-terms the economy is only growing a couple percent a year (real number unknowable because price inflation is not actually calculable). Moreover, the velocity of money is going up (higher velocity means that the same amount of money is used for more transactions).
Conclusion: 10% growth in money supply complete outstrips the actual growth of the economy => massive inflation is taking place.
We just don't see it in a broad measure because the Chinese government has been accumulating such a large surplus of our currency.
Actually I would rephrase that to be "most people are terrible at critical thinking"--by which I actually mean interpreting something for the purpose of criticizing it.
In my experience, people make and believe arguments that are rather poorly suited to the conclusion.
But at the same time, I think certain things mentioned in the article are overblown.
e.g., whether or not people click into the second page of search results. Personally I use google routinely to look-up websites that I already know. I'll recall something about the name of the site, but the DNS space is so crowded these days who can remember what sort of pseudo-english has been used to get a domain name. Enter google. Type in a few words--and wow, what I want appears in the top three. No need to search further.
An informal poll of my friends reveals they use google the same way.
I've also used google as a quick spell-checker before.
These experiences lead me to take a grain-of-salt with the 'using the first page only==stupidity' theory
Well. The trouble is actually OPEC. Production shares are set on the basis of reserve estimates. OPEC members have a strong incentive to inflate their reserve numbers so as to capture a larger share of the production.
When oil was primarily pumped by European and American oil companies (acting all over the world) they were public companies with substantial disclosure obligations: this meant detailed analysis and independent audits of how much oil they owned in the ground. After most oil production in the world was nationalized and run by State oil companies, the disclosures stopped.
So there is really very little public information about how much oil might be in the ground; well, we have public statements from the oil producing nations but little in the way of evidence. Amazingly, we don't even know how much oil is consumed. Wait, you're thinking: "I've seen barrels per day stats published". Sadly these numbers are discerned by counting tanker ships entering and leaving harbors.
For an introduction, I recommend reading "Twilight in the Desert". One caveat: this book proports to be technical; it isn't. Its mostly speculation and guess work. It is also rather redundant at times.
Most of the backlash against "Peak Oil" oil though _is_ deserved. Wells are said to run-dry when production becomes economically infeasible at current prices. There is still much oil in the ground. What has happened recently is that prices have risen faster than expected and suddenly reserve calculations have jumped up. Second, the question isn't so much about running out of oil as it is about limitations on how fast it can be pumped. If you pump a field too fast, you damage it. So the production rate is likely to peak+level off for quite some time before we run out of oil.
Obviously though is demand is so high that national oil companies "just pump harder" they will likely cause damage and experience a steep drop in production.
Oil is pumped harder by way of water injection. As a well ages, the oil pumped out becomes more and more contaminated with water. Actually 90% water, 10% oil isn't unusual. When this water fraction befores too big, production is abandoned (as too costly). Technology though is getting better and better about efficiently producing oil with an ever larger water cut.
Too much analysis has too many ceteris paribus assumptions.
This is untrue, and this whole story is dated--as of October 2.
See United States v. Arnold, 2006 U.S. Dist.
The central holding of this ruling is that the so called border-search exception to the 4th amendment (argued as implicit in the ability of the gov't to levy and enforce tariffs) cannot apply to personal effects such as notebook computer as the information it contains retains 4th amendment protection.
Consequently, searchs of your computer at the airport are illegal without a warrant.
Searches which do not access the information content--e.g., x-ray examination--are still allowed.
This case even had the "save the children" gateway to degrading the rights of the people--the defendent was found to have child pornography on his computer.
Look into "Why Multicast Protocols Don't Scale" by Eve Schooler.
One of the authors of RFC 2543,3261
But he fails to discuss the one area where message passing makes a certain amount of sense. Even a single computer is beginning to look more like a distributed system today: SMP is becoming increasingly common. In these situations communication and coordination is often costly. The trouble with a monolithic kernel comes in precisely what it makes easy: sharing memory and data structures--the very sort of thing that if not done very carefully destroys SMP performance, e.g., by cache-line stumping.
Taking a hybrid approach where a kernel thread runs on each CPU begins to make a certain amount of sense. Message passing becomes an analog to the interprocessor IPI messaging and shared memory bus-locked instructions.
In other words: microkernel concepts (not implementation) become a discipline that helps you avoid doing seemingly simple things that are actually quite cycle-time expensive.
Naturally though it isn't right to call this new idea "microkernel" it isn't subsystem partitioning per se. It is definitely a hybrid idea.
Yes Hyrbid kernels can be more than marketing hype. On that point Linus is definitely just being an attention-whore by making a sweeping generalization.
"eventually"
No, this is going to happen extremely soon. One of the flaws of the softupdates approach was always in the code complexity. There is a definite feeling within the developer community that softupdates will be jettisoned soon, to catch the signs of this google for bad_dir panics or see http://www.freebsd.org/cgi/query-pr.cgi?pr=93942 or http://people.freebsd.org/~pho/baddir.html
You may also notice in the release engineering notes for 6.1 several references to UFS deadlocks. All of these were long latent softupdate bugs, mistakes in the dependency tracking, etc, etc. It was quite the rollcoaster as those fixes when in, often followed by several other "no still not right" commits.
Softupdate's days are numbered. The one clear advantage that UFS has these days is being extremely robust in the presence of disk errors. The same cannot be said of ReiserFS or XFS wherein the on-disk data-structures are so optimized the filesystem is prone to fall-over rapidly when on a degrading disk. Ultimately though this sliver of a benefit from UFS cannot warrant staying with something far outmoded by proven better methods (journaling) and large disks.
Incidentially, it is historically wrong to call "softupdates" a response to journaling. Softupdates predates wide-spread acceptance of journaling filesystems and in its heyday enjoyed better performance (no longer).
Your comment seems sort of jealous. Let me change your perspective. This is what Freedom is really about: the freedom to choose. A long time FreeBSD user myself (eight years now), I love the FreeBSD userland. Leaving room for some degree of experience bias--every linux distribution I've tried has felt messy. I also dislike LILO and GRUB. I prefer the rc system to init runlevels. But these are all personal opinions. The point, though, is that someone with much less experience might also like these same things.
If this work is considerd good, I wouldn't be surprised to see lots of merged back into FreeBSD proper. That said, FreeBSD has always been the sysadmin's OS. Configuring the window manager just isn't their core-competency.
As for your driver complaint: prove that it matters. I've never had trouble. As for "more software" it is a certainty that you have that backwards. FreeBSD's linux compat layer is very good. FreeBSD can run just about any linux binary with little to no futzing. Most software already compiles on BSD natively or will almost certainly do so within a linux chroot. On top of this you have all of the software that was originally developed for FreeBSD.
There is a growing consensus that Infiniband is effectively a dead-end. Last year it would have been a tough call between Infiniband, Ethernet, and other more proprietary interconnects. The market seems to be favoring the backward compatibility of Ethernet, and now that low latency Ethernet (~200ns) appears to be at hand there does not appear to be any reason to prefer the less general tecnologies (Myrinet, Infiniband, etc). My friends at Myrinet hint that they are looking to using the Myrinet protocol layer on top of Ethernet and essentially EOLing the Myrinet physical layer.
Myrinet was fabulously advanced ten years ago when it spun out of Caltech, but alas, the rest of the world has caught-up.
To be fair the manual says: /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data; /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 &; /usr/local/pgsql/bin/createdb test; /usr/local/pgsql/bin/psql test;
What's the difference here? It uses the pgsql/bin wrappers. createdb does nothing more than execute the sql command "CREATE DATABASE" thus why one can simply connect to the database backend via psql and just type the CREATE DATABASE sql statement directly. I think this way has somewhat better error handling.
There are a bunch of configuration files in the pgsql directory (e.g. pg_hba.conf and postgresql.conf) once you know about these files... you can do just about anything.
More complicated? Seriously?
/where/the/database/should/live ...... ...
initdb -D
psql -U pgsql template1
\h create database
CREATE DATABASE
CREATE TABLE
It is *amazingly* easy to use and setup.