> If I have to compile it, I ain't running it,
> and I'm FAR from the only one.
The interesting variation here is that there is no need for you to know that things are being compiled.
Maybe installation takes a little longer, but the package gets built according to your local preferences and installation. This is just a packaging issue.
Whilst I don't recommend this is the right thing to do with large packages like KDE, Gnome, etc. this *is* the right thing to do for plug-in modules (think kernel drivers, X graphics drivers) which have a closer dependency on the app into which they insert.
For many things, source could become the default method of distribution, as long as it is wrapped nicely by dpkg and/or RPM who cares?
I suspect this won't happen. The reason is that there is (currently) insufficient motivation for people to consume less power than they need to.
Power seems to be cheap, a few pence/cents/whatever to keep lights running, run a computer, etc does not concern most (enough) people.
Laptops are different, since high power usage has a clearly perceived negative influence (shorter battery life).
Don't know what the answer is. Until we get lots of lovely clean (well, mostly) fusion power we have a problem.
But generally relying on people's good nature isn't enough motivation to pay 0.5% more for a 'greener' PC.
Not wishing to bait flames, but I think power is underpriced. Currently, power producers get to consume shared resources for little or no cost - hence the power consumers do not have the cost passed on to them.
Perhaps one day the idea that consumption of 'fresh air' (via pollution) (and any/all other items which get used up) is a privilege which should be paid for will seem as natural as the idea that you might need to pay for building/living on land. (Perhaps a poor analogy, since I suspect territorial humans have always had a sense of the value of land...ah well).
Basically, its the 'tragedy of the commons'. There is a shared resource which is being (over-)consumed because it isn't owned and charged out by someone and because those consuming it aren't being lent on by a bunch of angry villagers with pitchforks (I really need to work on these analogies).
If you throw into the mix that pollution in one country can cause acid rain in another (just as pollution in a river in one country can turn up in another downstream) and you have a hell of a mess which even per-country government intervention isn't going to dent.
I hope the free market types agree that something needs to be priced fairly (would it be a sensible market which prices a can of beans according to the raw cost of tin and neglected the cost of the beans, manafacture, marketing, etc) and that the green types see that simply imposing national taxes on certain types of consumption doesn't solve the problem.
Is it a file with the suffix '.mp3' (What if I rename it?)
Is it a file which the 'file' utility declares has the relevant magic numbers at the beginning?
What if I zip it?
What if I base64 encode (or uuencode) it?
What if I encrypt it?
In all cases, to play it I could have a wrapper script to undo the obusfaction and give me those MP3 bits.
An automatic job which deletes things is a stupid thing to do. Its an attempt at a technological solution to a social problem. If the ISP doesn't want you doing things, it should notify you in the Acceptable Use Policy (AUP).
If you violate the AUP you suffer - perhaps a warning and then junk the account, exactly as ISPs do with spam accounts.
Going round and deleting files is just foolish. Sigh.
I don't know of anything 'off the shelf' but there is a lot of technology you could use to help you.
What kind of link do you get over these satellites? Can you do IP? A mock 'serial line'? 'File transfer'?
If you are happy to have a crack at some configuration, you could check out any Mail Transfer Agent (MTA) with a 'uucp' interface (e.g. sendmail).
This oft-neglected means of transport requires only the ability to transfer files 'by some means' and includes goodies like compression. It is the source of those beautifully archaic 'user!serverA!serverB' type addresses (but you can get around that if you don't like it).
So...if you have the flexibilty, run a 'server class unix' (e.g. Linux) and a sendmail (or an equivalent which supports UUCP), buy the relevant O'Reilly book and you are away.
If you want/need windows compatibility then there is a reasonable chance of digging up some old Windows implementations (uucp may stand for 'unix to unix copy' but the protocol was implemented on various platforms).
Good luck, reply here if you'd like more info and I'll mail you.
> Reminds me of the old quote, "never underestimate the bandwidth of a speeding truck full of DAT tapes".
Which I think was updated with "or a 747 full of CD-ROMs".
ALthough as pointed out in the article, the problem being faced is latency, not bandwidth. (Have to admit, a 4-5 day ping would be fairly bad for Quake).
Isn't this an ideal application of satellite comms? High-bandwidth without significant latency requirements (they are currently dealing with 4-5 day latency, so 1s round trip shouldn't be a problem).
Hmm. This could lead to fun. Some character sets/character encodings allow different byte sequences to map to the same character.
(See the Unicode bugs recently in IIS, where a unicode representation of '../' is used to navigate upwards in the directories of the server to view files outside of the server root.)
Now, does a company have to register all possible permutations of byte sequences which all map to the same character sequence? As well as doing so in.com,.net and.org.
We'll see.
Re:I think there are some things to be cleared up
on
Is Novell Doomed?
·
· Score: 2
Fair enough that NDS predated LDAP, but X.500 has both 'proxying' (called chaining) *and* referrals. Referrals didn't get added to LDAP for a while but I'm pretty sure they were in X.500 back in its first incarnation in 1988.
There are lots of issues with X.500, primarily to do with the fact that no-one wanted to implement DAP on the client (and what is a 'generic' directory client for anyway?:-)
What Novell did was implement an X.500 server (NDS) with a specific *purpose* (user, server and printer management) but none of the X.500 access protocols (DAP, DSP etc). (They didn't need to - they put their own client protocols into OS extensions).
Later on they added LDAP and ended up with a nice Directory with some X.500 strengths and LDAP access.
Directories are becoming important. Novell have a nice solution because they have got some X.500 features in there. X.500 vendors have some nice solutions as well, but nothing like Novell's market presence in that arena.
[OK - so I work for an X.500 vendor. So shoot me.]
Off the top of my head, can't NFS be tranported over TCP instead of the more usual UDP?
In this case, you should be able to set things up on the server so that NFS only responds to data received over the ssh tunnel (hmm...how do you do this - ipchains on Linux?) and then you're away.
Clients first need to establish an ssh connection (providing the authentication you want) before they can do NFS. As a bonus, you can have ssh encrypt the NFS traffic (but you might not want to).
Have I had too little coffee today or would this be one way to go?
(Might require some tight configuration with current tools, but that could all be automated in principle).
The interesting thing about all this is that all these options are 'not quite as good' as the carbon/oxygen/water approach.
Hence natural selection suggests we won't find any:-)
You would need to construct an environment with an adundance of (one of) the 'exotic' alternatives and a scarcity of the common one before you would expect to see life.
On a slightly different note, perhaps the issue is not just 'proving' who you are.
Is there any requirement to be 'of sound mind'? Does it matter if people are too drunk too stand but able to vote with a mouse-click? What would happen if you turned up at a polling booth hammered out of your brain (but with your id etc) - would they let you vote?
How about if you turned up with someone else holding a gun to your head?
I wonder if for some applications (and I have no idea if voting is one of them) simply verifying who the person is (should that ever be reliably possible) might be insufficient.
Online banking? Transfer all my money into "Nasty Thug's Account" please. Yes, its me - here is my digital signature and biometric information.
At the moment ATMs have limits on how much cash you may retrieve, presumably to avoid this problem.
This is digital. Which means that if the quantity of light getting through drops from 100 Foobars to 30 Foobars you are still getting full bandwidth as long as digital 1 == "more than 20 Foobars". Of course if it drops below (or too near...) that you lose.
2) Beam interruptions
Yup, IP is 'best effort' delivery. You lose packets on the internet all the time (mostly due to congestion). As long as whatever is blocking moves 'soon' its all OK.
3) Pigeons
Break out the old technology. Someone patent the scarecrow quick.
I stand by the claims - I think its a miscommunication between us.
Steep learning curve => lots to learn before you can be productive.
Long learning curve => lots to learn in total.
Perl is easy to use to start being productive. You can get a lot done with a few features. Many perl coders just do open/close/read/write/simple regexp and are happy. You don't need to know the API to sockets unless you need to use that functionality. I don't see how C lays out a path for you to do that in a way which perl does not. In fact you get docs with a perl installation which you don't necessarily with a C compiler.
I'll rephrase. Yes, there is a shedload to learn in total, but that can be a gradual process which you need never complete - more gradual than with compiled languages.
And here are highlights my final final paragraph again, with emphasis.
Perl is not a *panacea*[1] ...use "a good enough tool..." which is *often*[2] perl.
[1] - solution to *every* problem [2] - often. Not always.
Hope that clears up the contradiction.
You are right that if I had the attitude "learn just one tool, use it always" then I would be a silly person. "I've got a hammer, that'll get those darn screws in". Thats dumb, no argument.
To stretch an analogy, I would perhaps say that instead of carrying around a set of socket wrenches, a saw and hedge clippers I'll just carry this natty little combi-tool with adjustable wrench and cutting accessories.
OK, so I still need to go to the tool shed if I want to cut a tree down, but I have a tool to hand which covers 90% of my needs in one package. Cool. Its why leatherman tools are popular. Same reasoning applies to perl (the 'swiss army chainsaw' gag is tries to get this across). It doesn't remove the need for other tools entirely, but it does cover a lot of cases.
I'm not surprised you think this if you look at perl as the "Practical Extraction and Report Language". Or as 'just' a sysadmin tool.
What perl is today is the ultimate glue language. Via the modules available (both those shipped with perl and those available via CPAN) you can interface to practically anything (Most network protocols, data formats, APIs, etc etc)
To be honest, 'bloat' in the language is only important for two things:
1) Performance. This is fair enough, lighter interpreted languages will (probably) start up faster. Once the interpreter is running, though, I don't see why an (unused) language feature will impact execution speed.
Also, "premature optimisation is the root of all evil". Most perl scripts are 'fast enough'. Those that are performance sensitive (e.g. CGI under Apache) can generally be speeded up (apache mod_perl).
2) Language breadth. This issue seems to be alluded to by people elsewhere in this dicussion. The mindset appears to be "if a feature is in perl then I'll have to learn it to be able to maintain perl". I can understand why feature bloat is a worry if you think this.
Perl has a huge feature set. The key thing to understand is that you DON'T NEED TO KNOW THE WHOLE LANGUAGE (sorry for shouting, its my main point and this is a long comment - wanted to make it stand out;-). I think there is a Larry Wall quote along the lines of "Perl's learning curve isn't steep, but it is long".
The point here is that you don't need to know that there is a language feature which will do your job in one line. If you know, you'll use it. If you don't know, you'll write 10 lines of perl instead. (or 50 or so in C to do the same job).
If you are maintaining someone else's code and they use a feature you don't recognise then you may need to look that up (the docs are good + install with perl). But the set of features you need to know is still not the whole language, its just the set of features which the author used.
Lastly, the number of features which can be abused to write unmaintainable code isn't really relevant. If a coder is sadistic enough to write unmaintainable code they only really need one or two language features (which all languages have).
Perl is not a panacea. However, instead of thinking "use the (one) right tool for the job" and learning C, C++, perl, python, java, scheme, eiffel etc, use "a good enough tool for the job" - which is often perl. Its easier to write in perl all the time and use a new feature than it is to learn a whole new language for every task.
On the humour front, I love a line I recall from a humorous TV program some time in the seventies/eighties (cold war still going strong). Sorry if this is offensive:-)
"The Americans are trying to make up for being late for the last two world wars by making sure they are really early for the next one".
Anyway, as to "many Americans perceive an arrogance from most britons" - that does seem quite possible.
But is this because Brits feel superior, because Americans feel inferior or because Americans feel Brits feel superior?
How do you perceive what I'm phrasing now? I'm just trying to be precise...
Whilst it seems that these people are nice and thorough, a couple of points:
1) If you are running one heck of a lot of processes/threads (same thing on Linux) you would expect the time spent in the scheduler to be big. That is unavoidable overhead of *all* thread models. (You can try and reduce it - thats good...but run enough threads and it will dominate).
2) {I am not a hacker but} If they are at the level of seeing improvments in the scheduler by tweaking things like structure layout to improve cacheline localilty then can we sure that the "low performance impact" IBM Kernel trace patch is not having an effect? What was the throughput like (i.e. the main benchmark measurement) like on a stock kernel?
3) If you move to a many-many scheduling model you *will* reduce the time spent in the kernel scheduler. However, you *will* spend time in your user-land scheduler. Which is the win?
I don't mean to suggest that these people don't have some good points (I hope that they develop patches and I hope that the best patch wins), but it is important not to jump to conclusions.
PS - I only skimmed the article, so I may have got the wrong end of the stick. I'm sure someone will put me right if so:-)
Talking off the top of my head (hey this *is* slashdot, right?) wasn't the easiest way to snoop a CRT to get at the light intensity variation?
i.e. We don't care where the electron beam is pointing, it is just illuminating (or not) one pixel at a time. So feed the light (any light, reflected or otherwise) from the room into something which chops it up at the right frequency (which is presumably one of a small number of standard ones) and you're away.
Whilst a windowless room should be proof against this (as long as you black out the gap under the door;-) simply closing the curtains probably won't help.
[And yes, I know light is also electromagnetic radiation. By 'EM' I mean the stuff which a Faraday cage is hoping to ground out. Sorry if this is insufficiently pedantic.]
Slashdot Mirror
> If I have to compile it, I ain't running it,
> and I'm FAR from the only one.
The interesting variation here is that there is no need for you to know that things are being compiled.
Maybe installation takes a little longer, but the package gets built according to your local preferences and installation. This is just a packaging issue.
Whilst I don't recommend this is the right thing to do with large packages like KDE, Gnome, etc. this *is* the right thing to do for plug-in modules (think kernel drivers, X graphics drivers) which have a closer dependency on the app into which they insert.
For many things, source could become the default method of distribution, as long as it is wrapped nicely by dpkg and/or RPM who cares?
Does anyone remember the 'Thing King'?
It's a way of describing virtual memory...
All that glisters is not gold.--William Shakespeare: Merchant of Venice, act ii. sc. 7.
HTH. HAND.
I suspect this won't happen. The reason is that there is (currently) insufficient motivation for people to consume less power than they need to.
Power seems to be cheap, a few pence/cents/whatever to keep lights running, run a computer, etc does not concern most (enough) people.
Laptops are different, since high power usage has a clearly perceived negative influence (shorter battery life).
Don't know what the answer is. Until we get lots of lovely clean (well, mostly) fusion power we have a problem.
But generally relying on people's good nature isn't enough motivation to pay 0.5% more for a 'greener' PC.
Not wishing to bait flames, but I think power is underpriced. Currently, power producers get to consume shared resources for little or no cost - hence the power consumers do not have the cost passed on to them.
Perhaps one day the idea that consumption of 'fresh air' (via pollution) (and any/all other items which get used up) is a privilege which should be paid for will seem as natural as the idea that you might need to pay for building/living on land. (Perhaps a poor analogy, since I suspect territorial humans have always had a sense of the value of land...ah well).
Basically, its the 'tragedy of the commons'. There is a shared resource which is being (over-)consumed because it isn't owned and charged out by someone and because those consuming it aren't being lent on by a bunch of angry villagers with pitchforks (I really need to work on these analogies).
If you throw into the mix that pollution in one country can cause acid rain in another (just as pollution in a river in one country can turn up in another downstream) and you have a hell of a mess which even per-country government intervention isn't going to dent.
I hope the free market types agree that something needs to be priced fairly (would it be a sensible market which prices a can of beans according to the raw cost of tin and neglected the cost of the beans, manafacture, marketing, etc) and that the green types see that simply imposing national taxes on certain types of consumption doesn't solve the problem.
So...what should be done?
Not as simple a question as you might think.
Is it a file with the suffix '.mp3' (What if I rename it?)
Is it a file which the 'file' utility declares has the relevant magic numbers at the beginning?
What if I zip it?
What if I base64 encode (or uuencode) it?
What if I encrypt it?
In all cases, to play it I could have a wrapper script to undo the obusfaction and give me those MP3 bits.
An automatic job which deletes things is a stupid thing to do. Its an attempt at a technological solution to a social problem. If the ISP doesn't want you doing things, it should notify you in the Acceptable Use Policy (AUP).
If you violate the AUP you suffer - perhaps a warning and then junk the account, exactly as ISPs do with spam accounts.
Going round and deleting files is just foolish. Sigh.
I don't know of anything 'off the shelf' but there is a lot of technology you could use to help you.
What kind of link do you get over these satellites? Can you do IP? A mock 'serial line'? 'File transfer'?
If you are happy to have a crack at some configuration, you could check out any Mail Transfer Agent (MTA) with a 'uucp' interface (e.g. sendmail).
This oft-neglected means of transport requires only the ability to transfer files 'by some means' and includes goodies like compression. It is the source of those beautifully archaic 'user!serverA!serverB' type addresses (but you can get around that if you don't like it).
So...if you have the flexibilty, run a 'server class unix' (e.g. Linux) and a sendmail (or an equivalent which supports UUCP), buy the relevant O'Reilly book and you are away.
If you want/need windows compatibility then there is a reasonable chance of digging up some old Windows implementations (uucp may stand for 'unix to unix copy' but the protocol was implemented on various platforms).
Good luck, reply here if you'd like more info and I'll mail you.
> Reminds me of the old quote, "never underestimate the bandwidth of a speeding truck full of DAT tapes".
Which I think was updated with "or a 747 full of CD-ROMs".
ALthough as pointed out in the article, the problem being faced is latency, not bandwidth. (Have to admit, a 4-5 day ping would be fairly bad for Quake).
Isn't this an ideal application of satellite comms? High-bandwidth without significant latency requirements (they are currently dealing with 4-5 day latency, so 1s round trip shouldn't be a problem).
Hmm. This could lead to fun. Some character sets/character encodings allow different byte sequences to map to the same character. .com, .net and .org.
(See the Unicode bugs recently in IIS, where a unicode representation of '../' is used to navigate upwards in the directories of the server to view files outside of the server root.)
Now, does a company have to register all possible permutations of byte sequences which all map to the same character sequence? As well as doing so in
We'll see.
Fair enough that NDS predated LDAP, but X.500 has both 'proxying' (called chaining) *and* referrals. Referrals didn't get added to LDAP for a while but I'm pretty sure they were in X.500 back in its first incarnation in 1988.
:-)
There are lots of issues with X.500, primarily to do with the fact that no-one wanted to implement DAP on the client (and what is a 'generic' directory client for anyway?
What Novell did was implement an X.500 server (NDS) with a specific *purpose* (user, server and printer management) but none of the X.500 access protocols (DAP, DSP etc). (They didn't need to - they put their own client protocols into OS extensions).
Later on they added LDAP and ended up with a nice Directory with some X.500 strengths and LDAP access.
Directories are becoming important. Novell have a nice solution because they have got some X.500 features in there. X.500 vendors have some nice solutions as well, but nothing like Novell's market presence in that arena.
[OK - so I work for an X.500 vendor. So shoot me.]
Off the top of my head, can't NFS be tranported over TCP instead of the more usual UDP?
In this case, you should be able to set things up on the server so that NFS only responds to data received over the ssh tunnel (hmm...how do you do this - ipchains on Linux?) and then you're away.
Clients first need to establish an ssh connection (providing the authentication you want) before they can do NFS. As a bonus, you can have ssh encrypt the NFS traffic (but you might not want to).
Have I had too little coffee today or would this be one way to go?
(Might require some tight configuration with current tools, but that could all be automated in principle).
The interesting thing about all this is that all these options are 'not quite as good' as the carbon/oxygen/water approach.
:-)
Hence natural selection suggests we won't find any
You would need to construct an environment with an adundance of (one of) the 'exotic' alternatives and a scarcity of the common one before you would expect to see life.
On a slightly different note, perhaps the issue is not just 'proving' who you are.
Is there any requirement to be 'of sound mind'? Does it matter if people are too drunk too stand but able to vote with a mouse-click? What would happen if you turned up at a polling booth hammered out of your brain (but with your id etc) - would they let you vote?
How about if you turned up with someone else holding a gun to your head?
I wonder if for some applications (and I have no idea if voting is one of them) simply verifying who the person is (should that ever be reliably possible) might be insufficient.
Online banking? Transfer all my money into "Nasty Thug's Account" please. Yes, its me - here is my digital signature and biometric information.
At the moment ATMs have limits on how much cash you may retrieve, presumably to avoid this problem.
Any way around this?
1) Fog slowing download time.
This is digital. Which means that if the quantity of light getting through drops from 100 Foobars to 30 Foobars you are still getting full bandwidth as long as digital 1 == "more than 20 Foobars". Of course if it drops below (or too near...) that you lose.
2) Beam interruptions
Yup, IP is 'best effort' delivery. You lose packets on the internet all the time (mostly due to congestion). As long as whatever is blocking moves 'soon' its all OK.
3) Pigeons
Break out the old technology. Someone patent the scarecrow quick.
I stand by the claims - I think its a miscommunication between us.
Steep learning curve => lots to learn before you can be productive.
Long learning curve => lots to learn in total.
Perl is easy to use to start being productive. You can get a lot done with a few features. Many perl coders just do open/close/read/write/simple regexp and are happy. You don't need to know the API to sockets unless you need to use that functionality. I don't see how C lays out a path for you to do that in a way which perl does not. In fact you get docs with a perl installation which you don't necessarily with a C compiler.
I'll rephrase. Yes, there is a shedload to learn in total, but that can be a gradual process which you need never complete - more gradual than with compiled languages.
And here are highlights my final final paragraph again, with emphasis.
Perl is not a *panacea*[1]
...use "a good enough tool..." which is *often*[2] perl.
[1] - solution to *every* problem
[2] - often. Not always.
Hope that clears up the contradiction.
You are right that if I had the attitude "learn just one tool, use it always" then I would be a silly person. "I've got a hammer, that'll get those darn screws in". Thats dumb, no argument.
To stretch an analogy, I would perhaps say that instead of carrying around a set of socket wrenches, a saw and hedge clippers I'll just carry this natty little combi-tool with adjustable wrench and cutting accessories.
OK, so I still need to go to the tool shed if I want to cut a tree down, but I have a tool to hand which covers 90% of my needs in one package. Cool. Its why leatherman tools are popular. Same reasoning applies to perl (the 'swiss army chainsaw' gag is tries to get this across). It doesn't remove the need for other tools entirely, but it does cover a lot of cases.
I'm not surprised you think this if you look at perl as the "Practical Extraction and Report Language". Or as 'just' a sysadmin tool.
;-). I think there is a Larry Wall quote along the lines of "Perl's learning curve isn't steep, but it is long".
What perl is today is the ultimate glue language. Via the modules available (both those shipped with perl and those available via CPAN) you can interface to practically anything (Most network protocols, data formats, APIs, etc etc)
To be honest, 'bloat' in the language is only important for two things:
1) Performance. This is fair enough, lighter interpreted languages will (probably) start up faster. Once the interpreter is running, though, I don't see why an (unused) language feature will impact execution speed.
Also, "premature optimisation is the root of all evil". Most perl scripts are 'fast enough'. Those that are performance sensitive (e.g. CGI under Apache) can generally be speeded up (apache mod_perl).
2) Language breadth. This issue seems to be alluded to by people elsewhere in this dicussion. The mindset appears to be "if a feature is in perl then I'll have to learn it to be able to maintain perl". I can understand why feature bloat is a worry if you think this.
Perl has a huge feature set. The key thing to understand is that you DON'T NEED TO KNOW THE WHOLE LANGUAGE (sorry for shouting, its my main point and this is a long comment - wanted to make it stand out
The point here is that you don't need to know that there is a language feature which will do your job in one line. If you know, you'll use it. If you don't know, you'll write 10 lines of perl instead. (or 50 or so in C to do the same job).
If you are maintaining someone else's code and they use a feature you don't recognise then you may need to look that up (the docs are good + install with perl). But the set of features you need to know is still not the whole language, its just the set of features which the author used.
Lastly, the number of features which can be abused to write unmaintainable code isn't really relevant. If a coder is sadistic enough to write unmaintainable code they only really need one or two language features (which all languages have).
Perl is not a panacea. However, instead of thinking "use the (one) right tool for the job" and learning C, C++, perl, python, java, scheme, eiffel etc, use "a good enough tool for the job" - which is often perl. Its easier to write in perl all the time and use a new feature than it is to learn a whole new language for every task.
Phew. Rant over.
Disclaimer: I'm British
:-)
On the humour front, I love a line I recall from a humorous TV program some time in the seventies/eighties (cold war still going strong). Sorry if this is offensive
"The Americans are trying to make up for being late for the last two world wars by making sure they are really early for the next one".
Anyway, as to "many Americans perceive an arrogance from most britons" - that does seem quite possible.
But is this because Brits feel superior, because Americans feel inferior or because Americans feel Brits feel superior?
How do you perceive what I'm phrasing now? I'm just trying to be precise...
Whilst it seems that these people are nice and thorough, a couple of points:
:-)
1) If you are running one heck of a lot of processes/threads (same thing on Linux) you would expect the time spent in the scheduler to be big.
That is unavoidable overhead of *all* thread models. (You can try and reduce it - thats good...but run enough threads and it will dominate).
2) {I am not a hacker but} If they are at the level of seeing improvments in the scheduler by tweaking things like structure layout to improve cacheline localilty then can we sure that the "low performance impact" IBM Kernel trace patch is not having an effect? What was the throughput like (i.e. the main benchmark measurement) like on a stock kernel?
3) If you move to a many-many scheduling model you *will* reduce the time spent in the kernel scheduler. However, you *will* spend time in your user-land scheduler. Which is the win?
I don't mean to suggest that these people don't have some good points (I hope that they develop patches and I hope that the best patch wins), but it is important not to jump to conclusions.
PS - I only skimmed the article, so I may have got the wrong end of the stick. I'm sure someone will put me right if so
What were the main benefits you expected to achieve from migrating to Linux and do you feel these have materialised?
Talking off the top of my head (hey this *is* slashdot, right?) wasn't the easiest way to snoop a CRT to get at the light intensity variation?
;-) simply closing the curtains probably won't help.
i.e. We don't care where the electron beam is pointing, it is just illuminating (or not) one pixel at a time. So feed the light (any light, reflected or otherwise) from the room into something which chops it up at the right frequency (which is presumably one of a small number of standard ones) and you're away.
Whilst a windowless room should be proof against this (as long as you black out the gap under the door
[And yes, I know light is also electromagnetic radiation. By 'EM' I mean the stuff which a Faraday cage is hoping to ground out. Sorry if this is insufficiently pedantic.]