I agree, though your license may be a little restrictive for some, and I'd put the program very firmly in the category of "not just below the horizon but also below ground". I don't care what Kevin Costner might say on the matter, you've got to let people know you've built it before they will give a damn. Although absolute numbers are inconsequential - and even the relative numbers are really not significant - if it's just right for those who do use it, it is just as important to consider those who WILL need it but who don't yet know the software even exists.
A project is not a success or a failure according to who do NOT use it. That is like arguing that English is a failure because 99.99% of lifeforms in the galaxy do not speak it. Well, why should they? Other than to get a spot on Star Trek, that is. The question is not one of who uses it, but who knows about it. Is the project on Freshmeat? (Answer: No, I looked.) Has it been mentioned on any medical websites? (Answer: Not obviously, though there was a brief mention from Rice University.) The only Wikipedia mention I could find was a single screenshot.
This doesn't make the project bad, but it does mean that it can't possibly reach its potential - in audience, in feedback, in actual day-to-day application, etc. Sure, you posted a link on Slashdot, which is excellent and is bound to get visitors to the site at the very least. However, I doubt rampaging hordes of neurologists visit here, which means although the numbers may be up, they're the wrong numbers. They're not the droids you are looking for.
What this means is that although Apple Corps is older, although Apple Inc. violated the terms of the original settlement by pushing first multimedia and then music, and although Apple Inc. has all the sensitivity of a Bavarian weevil on speed, it is Apple Inc. that wins the court case. Presumably on the grounds that even if they'd lost, they'd not have done anything any different.
Mind you, I'm not exactly impressed by Apple Corps attitude or behaviour in all of this. Or, indeed, in any of their business conduct. Nonetheless, the fact remains that if a trademark is to have meaning, legalized theft of that trademark is not acceptable.
Just double-checked and your prices are indeed correct. Since I could find no reference to a new source or a new extraction technique, I resorted to checking the wiki page for Osmium. I'm guessing I must have been looking at the price for Osmium-187, which is indeed about four times the price of gold, as that would explain why we were getting hugely different values. My apologies for not checking more carefully WHICH Osmium I was looking up the price for.
I agree. I'd extend what you wrote just a little to make your last point stronger - finding the problem is not sufficient, if the problem is so badly phrased as to be a problem in understanding what the problem is.
The "correct" way to list these problems is to have them easily searchable (as already said in parent post), but would then present a menu of different interpretations of what the problem actually is. Readers should be subject to exactly the amount of information they would find useful, neither saturated nor deprived. The first step in finding a solution is in defining the problem, but overdefining and underdefining are two common errors that lead to confusion.
...the huge chunk of Software Engineering dedicated to "Requirements Analysis" has nothing to do with finding out what people want. People developing Expert Systems long ago figured out that what people thought they wanted and what they actually would fund useful/usable were utterly disconnected.
To use the analogy of building a house, you know that you want a foundation. A solid foundation. A foundation that can take the strain of what you are likely to build on it. You do NOT ask prospective house-owners what colour it should be, what material it should be or what shape it should be. That is not their problem and should not be their problem. Those parameters may be influenced by what they want - if they want a ten-storey building, you probably want to think rather differently than if they want a single-wide mobile home - but that is the absolute limit that should be permitted in terms of external input.
When you build a piece of software, 99% of what is written will be invisible to the user. Only the 1% that constitutes the user interface has any bearing on the user whatsoever. So long as the guts are capable of performing the necessary tasks, those guts are your foundation. They are nothing to do with the user and should not be based on the user's requirements.
But they have to be based on requirements of some sort. So, what requirements are they based on? That one is so amazingly easy. You analyze not what the user wants, but what the user needs. These might be the same thing, but more than half the time they will be so astonishingly far off that you'd wonder if the requirements even relate to the same universe, never mind the same person. You then abstract those need requirements, formalize them in some way, reconcile any conflicts (which are almost always because the analysis was flawed) and then convert those requirements into a rigorous specification. No different from any other engineering discipline, except that other engineering disciplines don't have to work in quite the narrow range of tolerances as software engineers.
Once you have a specification, you reify it. You turn it into software. Traditionally, this has been by stepwise refinement - slowly moving the specification from the formal to the implementable and finally to the implemented. Modern "extreme programming" methods work by converting the specification into a test harness (which is a relatively trivial step) and then writing the code until the test harness validates it.
But none of this is new. It's long been said that if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization. It is precisely because other engineering disciplines have evolved from slap-dash methods to rigorous techniques over the past 10,000 years that software engineering has attempted to go directly to the inevitable end-result. Programmers should not have to wait until the year 32,000 before they can get a simple GUI to work - although some companies would seem to be heading in that direction. It is true that no major general-purpose software product has ever been "correctly" software engineered. This is not because the methods don't work, it's because companies would prefer to take your money now AND take your money later when the bug-fixed release comes out. Doing things right the first time is so unprofitable in today's world, so programmers don't bother.
The Wikipedia article on aggregated diamond nanorods is a little more helpful. However, there is a non-carbon material harder than diamond (ultrahard fullerine). What we seem to be seeing is that exotic materials form at the real extremes of pressure and/or temperature - that remain stable at normal atmospheric pressures and temperatures. We also know that crystals form very differently under extreme changes in pressure and/or temperature. This discovery isn't particularly earth-shattering in and of itself. What is interesting is that material science is continuing to evolve in the most unexpected of directions, with those involved being rather more creative in their research than has been typical in other disciplines.
Diamond (hardness of 10) is the hardest naturally-occuring mineral, but it is not the hardest material. Ultrahard fullerite is close to twice as hard as diamond. Boron-carbide, tungsten-carbide and silicon-carbide (hardness of 9 each) are only marginally softer. Osmium (as well as being the most expensive metal and the densest metal) is as close to diamond as pure metals get (hardness 7), but doesn't quite cut it. (Pun intended.)
The hardest known material, at present, would be aggregated diamond nanorods. (These are apparently produced by crushing buckyballs at extreme pressures. What "Get Fuzzy" makes of this is currently unknown.)
I beg to differ. Ok, Debian's list is long, but is hardly what I would call current or complete. CLHep (needed for Geant, which is actually listed, albeit many years out of date) is missing. NASA's CDF is missing. Seismic Unix (the Open Source tool for geoscience) is missing. Hell, I'll make it easy on you - just go to http://freshmeat.net/~imipak and fill in the gaps. Debian is great, I don't refute that in the least. But it is not the ultimate repository of knowledge.
No, neither am I, but I do make the claim that I probably know and use more obscure-but-useful packages for Linux than anyone else alive. I also make the claim that that obscurity is often precisely because nobody has thought of listing the packages anywhere, and not because of the quality of the package. When I ran FOLK - which Debian carried - I virtually doubled the kernel's size for the purpose of showcasing what people were missing. I can't tell you if I made any impact on the kernel by doing so, but I can tell you that there were more people aware such patches existed afterwards than before.
The same goes with software packages. Google is OK, but it's hard to find some of these packages - I call them Open Secret Source - and Debian's information (when a package exists) is limited. Sure, there's a lot of crap on Freshmeat, but you soon learn how to filter it out. Sure, there are un-updated records on Freshmeat, though I've occasionally had brain convulsions serious enough to try to go through and clean those up. Really, what is needed (IMHO) is a professionally-maintained dictionary of quality products, which is always current (to within a week or two) and properly screened to ensure that the software is any good at what it does. Such indexes exist for Windows, but are usually pretty pathetic, but none that I know of exist for Linux. We've got the voluntary system only, which means quality will always be unknown and incompleteness will always be guaranteed.
It seems perfectly easy to have the page use an SSI to patch in a "traditional" headline for human readers and a "searchable" headline for webcrawlers. It involves a conditional SSI that checks the browser ID, an else clause, and an end of conditional. Three lines. Since these pages are all dynamically generated from a template, all you do is surround each of the headline areas. A few minutes work, not much more, and if the conditional makes an error, the alternative is perfectly good.
(Search engines don't like you replacing the entire page with a bunch of keywords, but since the engine is going to get the massaged headline no matter what, improving the interface for the users doesn't seem to be too great a sacrifice.)
The problem is that finding the pieces can be extremely difficult. There is nothing that a user can want that can't be done using the right set of kernel patches, the right set of libraries, the right set of applications. But putting these together is almost impossible unless you are one of the very very few who actually knows where things are and what to look for.
(I'm amazed by the number of hard-core Linux programmers I've met who have never even heard of Freshmeat. They've simply never heard of anyone offering a listing of what software was out there - and Freshmeat barely scratches the surface in a lot of areas. They use the tools they know of, imagining those to be the only ones to exist.)
Want a GUI but don't want X? Fine, no problem. Some aren't maintained all that well, but that's not the point. The point is not what could be better, the point is what exists in the first place. Code improvements will happen, if critical mass is reached on the userbase, but critical mass is impossible to achieve if nobody ever hears about these efforts. Don't blame Linux for "only" having one archaic GUI, when it actually has closer to twenty, if anyone made the effort to look. (Those are actual GUIs, not libraries or desktops for X. X isn't needed for, or used by, any of them.)
Want to run binaries for another Intel-based OS under Linux? I only know of five ways to do that at the moment. That's less developed. Not Linux' fault if the distros either don't provide them or don't make them simple to use. Not Linux' fault if users don't know about them, or only know about one or two. So neither the distros nor the users have any business blaming Linux for their own faults and failures.
Want hard real-time multimedia? Now we're down to about four broad solutions, with two options (microsecond precision or nanosecond precision), so that's eight ways to achieve this. Not bad. How many does the typical hardcore Linux gamer or musician install? None? Then my sympathies lie more with the LKML folk. They have achieved near-miracles and it must bother them some to be told that stuff that's been out there for two or three years "doesn't exist".
So am I doing anything different? Yes. I'm fighting the ignorance as best as I can, although my efforts are necessarily limited. It's hard work and I get a great deal of flammage for doing nothing more than letting people know that solutions do exist. My impact has probably been insignificant, compared to that of most Linux advocates, as I'm less concerned with paving over the gigantic holes of obliviousness than I am with filling in the ruts of obscurity. However, how is anyone to know that the ruts needn't be there, if nobody takes the time to show the alternative?
All that I ask is that when anybody - whoever that is, whenever that is - takes the time to show you why Linux doesn't have the limitations it is ascribed as having, please just take the time to have some faith that the system you use, and perhaps like, may actually be better than you once thought. Doesn't it feel better to know that what you perceive as a limitation of a given setup is neither your imagination nor unfixable, and that indeed a fix likely already exists. All you have to do is apply it. Then, the limitation ceases to exist.
She only lost one battle like that. Mind you, that was sufficient. Earlier on, she'd ambushed a Roman legion and massacred the lot of them, and burned two Roman cities to the ground. Her defeat was at the hands of one of the best Roman commanders and two elite Roman legions who had earlier slaughtered the druids and defenders of the Isle of Anglsey, even though they had to wade through to water to get there. It is also worth noting that the Celts who marched with Hannibal were also massacred by the Romans - Hannibal used them as bait, so he could encircle the Romans.
So, compared to other Celts of the time, Bodecca actually did rather well, surviving three battles against Roman forces and only being beaten by a tactical genius. When compared against the tactical giants of Hannibal, Julius Caesar, Sun Tzu, Napoleon, Rommel and James Dalton*, Bodecca doesn't fare so well. However, it seems fairer to compare her against any other Celtic commander of the time, and none of the others come remotely close.
*Acting Commissary James Dalton is believed to have been the real leader of the defence of Rorke's Drift, in which 110 British soldiers held off 5,000+ Zulus armed with rifles for about 10 hours. As with all of the other commanders on the list, his ethics could not be called civilized, and morality was definitely something he'd have to look up in a dictionary, but you don't need ethics or morality to win fights.
...this means that a profit is a negatively negative profit (Profit = --Profit). Furthermore, a profit is equal to the RMS negative profit (Profit = sqrt((-Profit * -Profit)/1). Worst of all, the profit was exponentially logarithmic (Profit = log(exp(Profit)))!
Alan Garner went from writing successful children's fantasy to writing swords-and-sorcery novels for adults. Tolkien went from The Hobbit to Lord of The Rings, although that's slightly different as he'd worked on early parts of The Silmarilian from before The Hobbit. Terry Pratchett has ventured into young kids books (The Diggers, Only You Can Save Mankind, etc) and also more sophisticated stories (Good Omens), as side projects from his Discworld series. I can't remember if C.S. Lewis did the Narnia stories before or after Out Of The Silent Planet.
The common theme is that these all play to a totally different audience. Different age bracket, different interests, different emphasis, even if the basic genre always stayed the same. On that basis, I'm going to guess JKR will do the same. She has already said she will use a pen-name, so that the book will stand or fall on its own merits - which is a brave but actually very respectable and civilized standpoint. It does mean, though, that we won't know she is the author for some time. I expect her next books to be aimed more at middle-aged women, but more along the Mary Stewart style than the Mills And Boone. That guess is because I can't see how much more opposite you could get and stay in the same genre.
(Here's one possibility. There are claims that Bodecca - the Icini Queen who launched one of the most terrifying rebellions Rome ever faced and is used to this day as an icon of terror for Italian children - was a druidess. Nobody I know of has ever written a fantasy novel based on Bodecca, let alone one that ventured into the mysticism and old magic of that era. I could easily see JKR being able to turn such a figure into a truly powerful lead character - a vengeance-seeking blood-thirsty sword-wielding Hermione on steroids. Though she, no doubt, has plenty of ideas of her own.)
Block devices lend themselves nicely to offload engines, as you can RDMA the processed data into a thin driver that basically just offers the data to the userspace application in the expected format but does little or no actual work. You can even do direct data placement into the application and just use the kernel as a notification system. So, the smarter the hardware, the more you can get from being able to handle large chunks of data or large numbers of commands in a single shot. Arguably, you can still do some of this with a character device - you can RDMA into the kernel, but direct data placement would be a headache and I can't see you getting much from either offloading or kernel bypass.
However, that is actually one of the benefits of character devices. They're lightweight on the hardware and the software, making "routine" activity extremely fast and efficient, and making it easier to be sure everything is correct and robust. For most "normal" activity, you're not wanting to do anything particularly complex. Wordprocessors, by and large, are not based on scatter/gather algorithms, and it is rare to find non-sequential MP3s. Also bear in mind that most CPUs outpace memory tens, if not hundreds, of time over - they are certainly going to outpace any peripherals a person might have. Why accelerate the kernel, if the kernel isn't the bottleneck? That just risks introducing bugs with no obvious gain.
Myself, I believe that it's stupid to design limitations into one component because of limitations in another. The limitations in the other component will be subject to change, but the designed limitations will hang around for much longer. I also think it's stupid to look at current typical use. Current typical use is dictated by what is currently practical. If you change what is practical, you will change what is typical use. The OS and the users are not independent of one another. What people wanted is unimportant, it's what people want to want that should dictate what OS writers should want to offer. And, yes, I believe that direct data placement has the potential to eliminate the need for both binary-only drivers and heavy-weight kernels.
(Linux contains a huge number of very low-level drivers, and is limited in what it can absorb in the way of new high-level functionality because of the risk of breakage and the difficulty of maintaining such a gigantic tree. If those had all been intelligent peripherals, the same amount of effort and coding would have produced a kernel with staggering capabilities and electronic superpowers. The drivers can't go away, even if intelligent devices replace the dumb ones of today, because people will use legacy stuff. Actually, it's worse. As Microsoft showed with Winmodems and Winprinters, it's possible to sell people dumber-than-dumb devices and even heavier-weight software that does a worse job, slower.)
Heh! We're always "just thinking aloud". That's how most discoveries are made. That's why most discoveries are made by people with a good imagination and the ability to start a sentence with "maybe". (I will probably never make a discovery, for that reason. I'm good at making connections, but lousy at the musings and speculative thinking that's needed. That is why I can tell you how certain connections could work, if a given theory was assumed to be true, but you're more likely to be the person to come up with a good theory in the first place.)
Skara Brae was somewhere between 10-15 houses, built as a unified structure with two totally enclosed primary corridors linked to by shorter corridors from each of the houses. The space between the houses was filled in, although there is some uncertainty as to whether the outside was surrounded by earth/trash initially or whether that was simply accumulation. Either way, the houses would be better regarded as condos in a single apartment building, rather than as separate structures. There would have been a single roof, albeit a complicated shape, over the whole of the interior, and every part of the interior could be reached by remaining entirely between walls and under the roof.
Provided everyone took care of the security of their condo, this made for something virtually unassailable. Two small doorways to the outside world could easily be blocked off or defended by minimal guards, assuming anyone could find a place that may have been disguised as a small hill. It would certainly have been hard to see, from any distance. This would have required a great deal of trust between residents. For much the same reason, fire risks, disease management and just about all other risks and responsibilities would have been totally shared, in a way that discrete housing makes unnecessary through isolation.
Finally, Skara Brae housed probably 100 to 150 people, according to the archaeological studies carried out there. To house so many people in so few rooms would have meant that the population had to have operated on some sort of a shift basis. You simply can't fit that many people into such a small space, unless they are there at different times. Nightshift in the stone age would have been limited, particularly that far north, which means that they understood at least the basics of division of labour and coordination between groups under different leadership. It could not have been particularly stratified, as in having different classes above each other, but would have been structured closer to the way a modern University is run, with a mix of layers and divisions. This would have made specialism possible, in a way that does not appear to have existed in Britain until the Bronze Age.
Stone-age cultures elsewhere in the British Isles don't show that level of interdependence, and specialism would have been almost impossible. There is extensive evidence of stratification, but not really much for labour division outside of that. Multiple hierarchies simply didn't exist. They would also have been hunter-gatherers, as farming did not exist at that time. However, they would have had a major problem. That far south, the food would spoil faster, so gather/store would have been extremely difficult. Beyond guard duty, it is unlikely there would have been a night-shift -- they would have needed everyone to hunt for food during the day.
The whole mindset seems so totally different - one is bordering on socialism, the other is feudal. Simply moving from one location to another can't possibly produce such a drastic change in society. Neither could have survived for long in the land of the other, using their familiar way of life, so it seems unreasonable to assume they did so.
Am I overstating the case for a difference? Possibly not. The inhabitants of Skara Brae were most likely Stone Age peoples from southern France, northern Spain, who travelled to Britain when it was literally possible to walk there. The inhabitants of southeastern England, at that time, were pre
Oh, I imagine some things have changed. Just not the things they benchmarked. I'll be fair and accept that this was their first attempt at a kernel benchmark, but there's no point in comparing the identical. The vanilla and stable 2.6.19 kernels are fair only if you test the things that make 2.6.20 significantly different.
A better comparison would be against the kernels in the unpatched Fedora Core 6 and Red Hat Enterprise.
I would say you are correct. Legends get associated with all kinds of standing stones. The one from near where I used to live ("Robin Hood's Picking Stones") has been classed as everything from sacrificial stones to a medieval archery range. (Current theory is that it is the remains of a double-headed Mercian stone cross, but I can't say I'm completely convinced. It's different enough from other Mercian stone crosses I've seen to convince me that there's more to the story.)
That sounds a reasonable picture. If it looked way out, I'd be googling for the source, but I think it reasonable to say that what you describe is very likely what was actually said. I think what bothers me the most is that this is about the same age as the second-generation Skara Brae, follows the same basic design, but is definitely more primitive and if you assume layout follows some form of social norm, there is a different social structure present.
Have to correct you there. Theories are always based on existing data, for the purpose of making predictions about the unknown. When a theory is made where there is no data, the tendency is to try to make the data - when it becomes available - fit the theory. The theory should evolve to fit facts, facts should never be coerced into fitting theories. The former is science, the latter is religion.
Slashdot Mirror
A project is not a success or a failure according to who do NOT use it. That is like arguing that English is a failure because 99.99% of lifeforms in the galaxy do not speak it. Well, why should they? Other than to get a spot on Star Trek, that is. The question is not one of who uses it, but who knows about it. Is the project on Freshmeat? (Answer: No, I looked.) Has it been mentioned on any medical websites? (Answer: Not obviously, though there was a brief mention from Rice University.) The only Wikipedia mention I could find was a single screenshot.
This doesn't make the project bad, but it does mean that it can't possibly reach its potential - in audience, in feedback, in actual day-to-day application, etc. Sure, you posted a link on Slashdot, which is excellent and is bound to get visitors to the site at the very least. However, I doubt rampaging hordes of neurologists visit here, which means although the numbers may be up, they're the wrong numbers. They're not the droids you are looking for.
Mind you, I'm not exactly impressed by Apple Corps attitude or behaviour in all of this. Or, indeed, in any of their business conduct. Nonetheless, the fact remains that if a trademark is to have meaning, legalized theft of that trademark is not acceptable.
Just double-checked and your prices are indeed correct. Since I could find no reference to a new source or a new extraction technique, I resorted to checking the wiki page for Osmium. I'm guessing I must have been looking at the price for Osmium-187, which is indeed about four times the price of gold, as that would explain why we were getting hugely different values. My apologies for not checking more carefully WHICH Osmium I was looking up the price for.
The "correct" way to list these problems is to have them easily searchable (as already said in parent post), but would then present a menu of different interpretations of what the problem actually is. Readers should be subject to exactly the amount of information they would find useful, neither saturated nor deprived. The first step in finding a solution is in defining the problem, but overdefining and underdefining are two common errors that lead to confusion.
Are you accusing Linus of jumping the gun? We all know from court statements that the stolen code isn't to be added until Linux 2.7!
Ha! Then you explain why carbonated drinks are so popular! :)
Last I looked, Osmium is around 4.5 times that of gold.
To use the analogy of building a house, you know that you want a foundation. A solid foundation. A foundation that can take the strain of what you are likely to build on it. You do NOT ask prospective house-owners what colour it should be, what material it should be or what shape it should be. That is not their problem and should not be their problem. Those parameters may be influenced by what they want - if they want a ten-storey building, you probably want to think rather differently than if they want a single-wide mobile home - but that is the absolute limit that should be permitted in terms of external input.
When you build a piece of software, 99% of what is written will be invisible to the user. Only the 1% that constitutes the user interface has any bearing on the user whatsoever. So long as the guts are capable of performing the necessary tasks, those guts are your foundation. They are nothing to do with the user and should not be based on the user's requirements.
But they have to be based on requirements of some sort. So, what requirements are they based on? That one is so amazingly easy. You analyze not what the user wants, but what the user needs. These might be the same thing, but more than half the time they will be so astonishingly far off that you'd wonder if the requirements even relate to the same universe, never mind the same person. You then abstract those need requirements, formalize them in some way, reconcile any conflicts (which are almost always because the analysis was flawed) and then convert those requirements into a rigorous specification. No different from any other engineering discipline, except that other engineering disciplines don't have to work in quite the narrow range of tolerances as software engineers.
Once you have a specification, you reify it. You turn it into software. Traditionally, this has been by stepwise refinement - slowly moving the specification from the formal to the implementable and finally to the implemented. Modern "extreme programming" methods work by converting the specification into a test harness (which is a relatively trivial step) and then writing the code until the test harness validates it.
But none of this is new. It's long been said that if builders built buildings the way programmers wrote programs, the first woodpecker that came along would destroy civilization. It is precisely because other engineering disciplines have evolved from slap-dash methods to rigorous techniques over the past 10,000 years that software engineering has attempted to go directly to the inevitable end-result. Programmers should not have to wait until the year 32,000 before they can get a simple GUI to work - although some companies would seem to be heading in that direction. It is true that no major general-purpose software product has ever been "correctly" software engineered. This is not because the methods don't work, it's because companies would prefer to take your money now AND take your money later when the bug-fixed release comes out. Doing things right the first time is so unprofitable in today's world, so programmers don't bother.
The Wikipedia article on aggregated diamond nanorods is a little more helpful. However, there is a non-carbon material harder than diamond (ultrahard fullerine). What we seem to be seeing is that exotic materials form at the real extremes of pressure and/or temperature - that remain stable at normal atmospheric pressures and temperatures. We also know that crystals form very differently under extreme changes in pressure and/or temperature. This discovery isn't particularly earth-shattering in and of itself. What is interesting is that material science is continuing to evolve in the most unexpected of directions, with those involved being rather more creative in their research than has been typical in other disciplines.
The hardest known material, at present, would be aggregated diamond nanorods. (These are apparently produced by crushing buckyballs at extreme pressures. What "Get Fuzzy" makes of this is currently unknown.)
Software isn't hard, and neither are brains. They are both soft and squishy.
No, neither am I, but I do make the claim that I probably know and use more obscure-but-useful packages for Linux than anyone else alive. I also make the claim that that obscurity is often precisely because nobody has thought of listing the packages anywhere, and not because of the quality of the package. When I ran FOLK - which Debian carried - I virtually doubled the kernel's size for the purpose of showcasing what people were missing. I can't tell you if I made any impact on the kernel by doing so, but I can tell you that there were more people aware such patches existed afterwards than before.
The same goes with software packages. Google is OK, but it's hard to find some of these packages - I call them Open Secret Source - and Debian's information (when a package exists) is limited. Sure, there's a lot of crap on Freshmeat, but you soon learn how to filter it out. Sure, there are un-updated records on Freshmeat, though I've occasionally had brain convulsions serious enough to try to go through and clean those up. Really, what is needed (IMHO) is a professionally-maintained dictionary of quality products, which is always current (to within a week or two) and properly screened to ensure that the software is any good at what it does. Such indexes exist for Windows, but are usually pretty pathetic, but none that I know of exist for Linux. We've got the voluntary system only, which means quality will always be unknown and incompleteness will always be guaranteed.
(Search engines don't like you replacing the entire page with a bunch of keywords, but since the engine is going to get the massaged headline no matter what, improving the interface for the users doesn't seem to be too great a sacrifice.)
(I'm amazed by the number of hard-core Linux programmers I've met who have never even heard of Freshmeat. They've simply never heard of anyone offering a listing of what software was out there - and Freshmeat barely scratches the surface in a lot of areas. They use the tools they know of, imagining those to be the only ones to exist.)
Want a GUI but don't want X? Fine, no problem. Some aren't maintained all that well, but that's not the point. The point is not what could be better, the point is what exists in the first place. Code improvements will happen, if critical mass is reached on the userbase, but critical mass is impossible to achieve if nobody ever hears about these efforts. Don't blame Linux for "only" having one archaic GUI, when it actually has closer to twenty, if anyone made the effort to look. (Those are actual GUIs, not libraries or desktops for X. X isn't needed for, or used by, any of them.)
Want to run binaries for another Intel-based OS under Linux? I only know of five ways to do that at the moment. That's less developed. Not Linux' fault if the distros either don't provide them or don't make them simple to use. Not Linux' fault if users don't know about them, or only know about one or two. So neither the distros nor the users have any business blaming Linux for their own faults and failures.
Want hard real-time multimedia? Now we're down to about four broad solutions, with two options (microsecond precision or nanosecond precision), so that's eight ways to achieve this. Not bad. How many does the typical hardcore Linux gamer or musician install? None? Then my sympathies lie more with the LKML folk. They have achieved near-miracles and it must bother them some to be told that stuff that's been out there for two or three years "doesn't exist".
So am I doing anything different? Yes. I'm fighting the ignorance as best as I can, although my efforts are necessarily limited. It's hard work and I get a great deal of flammage for doing nothing more than letting people know that solutions do exist. My impact has probably been insignificant, compared to that of most Linux advocates, as I'm less concerned with paving over the gigantic holes of obliviousness than I am with filling in the ruts of obscurity. However, how is anyone to know that the ruts needn't be there, if nobody takes the time to show the alternative?
All that I ask is that when anybody - whoever that is, whenever that is - takes the time to show you why Linux doesn't have the limitations it is ascribed as having, please just take the time to have some faith that the system you use, and perhaps like, may actually be better than you once thought. Doesn't it feel better to know that what you perceive as a limitation of a given setup is neither your imagination nor unfixable, and that indeed a fix likely already exists. All you have to do is apply it. Then, the limitation ceases to exist.
So, compared to other Celts of the time, Bodecca actually did rather well, surviving three battles against Roman forces and only being beaten by a tactical genius. When compared against the tactical giants of Hannibal, Julius Caesar, Sun Tzu, Napoleon, Rommel and James Dalton*, Bodecca doesn't fare so well. However, it seems fairer to compare her against any other Celtic commander of the time, and none of the others come remotely close.
*Acting Commissary James Dalton is believed to have been the real leader of the defence of Rorke's Drift, in which 110 British soldiers held off 5,000+ Zulus armed with rifles for about 10 hours. As with all of the other commanders on the list, his ethics could not be called civilized, and morality was definitely something he'd have to look up in a dictionary, but you don't need ethics or morality to win fights.
...this means that a profit is a negatively negative profit (Profit = --Profit). Furthermore, a profit is equal to the RMS negative profit (Profit = sqrt((-Profit * -Profit)/1). Worst of all, the profit was exponentially logarithmic (Profit = log(exp(Profit)))!
The common theme is that these all play to a totally different audience. Different age bracket, different interests, different emphasis, even if the basic genre always stayed the same. On that basis, I'm going to guess JKR will do the same. She has already said she will use a pen-name, so that the book will stand or fall on its own merits - which is a brave but actually very respectable and civilized standpoint. It does mean, though, that we won't know she is the author for some time. I expect her next books to be aimed more at middle-aged women, but more along the Mary Stewart style than the Mills And Boone. That guess is because I can't see how much more opposite you could get and stay in the same genre.
(Here's one possibility. There are claims that Bodecca - the Icini Queen who launched one of the most terrifying rebellions Rome ever faced and is used to this day as an icon of terror for Italian children - was a druidess. Nobody I know of has ever written a fantasy novel based on Bodecca, let alone one that ventured into the mysticism and old magic of that era. I could easily see JKR being able to turn such a figure into a truly powerful lead character - a vengeance-seeking blood-thirsty sword-wielding Hermione on steroids. Though she, no doubt, has plenty of ideas of her own.)
On page 421, it is revealed that Salazaar Slytherin was actually a secret co-founder of Microsoft and contributed Clippy to Windows.
Then Azhkaban could be used to promote Hovis brread - after all, there's nowt taken out.
However, that is actually one of the benefits of character devices. They're lightweight on the hardware and the software, making "routine" activity extremely fast and efficient, and making it easier to be sure everything is correct and robust. For most "normal" activity, you're not wanting to do anything particularly complex. Wordprocessors, by and large, are not based on scatter/gather algorithms, and it is rare to find non-sequential MP3s. Also bear in mind that most CPUs outpace memory tens, if not hundreds, of time over - they are certainly going to outpace any peripherals a person might have. Why accelerate the kernel, if the kernel isn't the bottleneck? That just risks introducing bugs with no obvious gain.
Myself, I believe that it's stupid to design limitations into one component because of limitations in another. The limitations in the other component will be subject to change, but the designed limitations will hang around for much longer. I also think it's stupid to look at current typical use. Current typical use is dictated by what is currently practical. If you change what is practical, you will change what is typical use. The OS and the users are not independent of one another. What people wanted is unimportant, it's what people want to want that should dictate what OS writers should want to offer. And, yes, I believe that direct data placement has the potential to eliminate the need for both binary-only drivers and heavy-weight kernels.
(Linux contains a huge number of very low-level drivers, and is limited in what it can absorb in the way of new high-level functionality because of the risk of breakage and the difficulty of maintaining such a gigantic tree. If those had all been intelligent peripherals, the same amount of effort and coding would have produced a kernel with staggering capabilities and electronic superpowers. The drivers can't go away, even if intelligent devices replace the dumb ones of today, because people will use legacy stuff. Actually, it's worse. As Microsoft showed with Winmodems and Winprinters, it's possible to sell people dumber-than-dumb devices and even heavier-weight software that does a worse job, slower.)
Skara Brae was somewhere between 10-15 houses, built as a unified structure with two totally enclosed primary corridors linked to by shorter corridors from each of the houses. The space between the houses was filled in, although there is some uncertainty as to whether the outside was surrounded by earth/trash initially or whether that was simply accumulation. Either way, the houses would be better regarded as condos in a single apartment building, rather than as separate structures. There would have been a single roof, albeit a complicated shape, over the whole of the interior, and every part of the interior could be reached by remaining entirely between walls and under the roof.
Provided everyone took care of the security of their condo, this made for something virtually unassailable. Two small doorways to the outside world could easily be blocked off or defended by minimal guards, assuming anyone could find a place that may have been disguised as a small hill. It would certainly have been hard to see, from any distance. This would have required a great deal of trust between residents. For much the same reason, fire risks, disease management and just about all other risks and responsibilities would have been totally shared, in a way that discrete housing makes unnecessary through isolation.
Finally, Skara Brae housed probably 100 to 150 people, according to the archaeological studies carried out there. To house so many people in so few rooms would have meant that the population had to have operated on some sort of a shift basis. You simply can't fit that many people into such a small space, unless they are there at different times. Nightshift in the stone age would have been limited, particularly that far north, which means that they understood at least the basics of division of labour and coordination between groups under different leadership. It could not have been particularly stratified, as in having different classes above each other, but would have been structured closer to the way a modern University is run, with a mix of layers and divisions. This would have made specialism possible, in a way that does not appear to have existed in Britain until the Bronze Age.
Stone-age cultures elsewhere in the British Isles don't show that level of interdependence, and specialism would have been almost impossible. There is extensive evidence of stratification, but not really much for labour division outside of that. Multiple hierarchies simply didn't exist. They would also have been hunter-gatherers, as farming did not exist at that time. However, they would have had a major problem. That far south, the food would spoil faster, so gather/store would have been extremely difficult. Beyond guard duty, it is unlikely there would have been a night-shift -- they would have needed everyone to hunt for food during the day.
The whole mindset seems so totally different - one is bordering on socialism, the other is feudal. Simply moving from one location to another can't possibly produce such a drastic change in society. Neither could have survived for long in the land of the other, using their familiar way of life, so it seems unreasonable to assume they did so.
Am I overstating the case for a difference? Possibly not. The inhabitants of Skara Brae were most likely Stone Age peoples from southern France, northern Spain, who travelled to Britain when it was literally possible to walk there. The inhabitants of southeastern England, at that time, were pre
A better comparison would be against the kernels in the unpatched Fedora Core 6 and Red Hat Enterprise.
I would say you are correct. Legends get associated with all kinds of standing stones. The one from near where I used to live ("Robin Hood's Picking Stones") has been classed as everything from sacrificial stones to a medieval archery range. (Current theory is that it is the remains of a double-headed Mercian stone cross, but I can't say I'm completely convinced. It's different enough from other Mercian stone crosses I've seen to convince me that there's more to the story.)
That sounds a reasonable picture. If it looked way out, I'd be googling for the source, but I think it reasonable to say that what you describe is very likely what was actually said. I think what bothers me the most is that this is about the same age as the second-generation Skara Brae, follows the same basic design, but is definitely more primitive and if you assume layout follows some form of social norm, there is a different social structure present.
Have to correct you there. Theories are always based on existing data, for the purpose of making predictions about the unknown. When a theory is made where there is no data, the tendency is to try to make the data - when it becomes available - fit the theory. The theory should evolve to fit facts, facts should never be coerced into fitting theories. The former is science, the latter is religion.