(From experience, in a Honda HR-V) CVT gives you really shitty mileage (and performance) though, even worse than a torque converted auto box. Still, it's one fewer thing to concentrate on, and given the target market, that's a really good idea.
CVTs don't work with higher power engines because they don't transmit a lot of torque. But they work well with smaller, low power engines. The Dutch DAF cars used them for years, and they were noted for there good fuel economy.
I'm not an SUV cheerleader by any means, but to suggest that all SUVs have poor crash ratings is mere conjecture. I found some crash ratings that contradict your assertion in 30 seconds.
Speaking as someone who drives an SUV, no vehicle with a rigid chassis (as most SUVs have) is going to be anything like as safe in a head-on collision as something with proper crumple zones.
I agree that you need to have a rough idea about how the whole stack works. But we no longer expect all computer science students to be able to wire up NAND gates from discrete valves or transistors.
I agree a little more with the parent of your post because, I find that it's really important to be able to reason about what your code is *doing*. To reason code, one must understand what high-level language X is doing with it. A lot of mistakes that I see are made because people don't understand how their code is executing.
It doesn't take too much to learn. A bit of assembler, write some basic stuff, so that one can get the idea of it. Write a bit of C for a microcontroller, throw in a few pointers, so that one has a working understanding of stack/heap memory, function pointers and such. Only then will you be able to understand how the CLR works, how it tries to save you from resource leaks, and how you can still screw it all up.
Ignorance is not bliss when it comes to working in higher level abstractions. One needs to have some basic idea of what the abstraction is doing.
OK, I think you're wrong. And to explain why I think you're wrong I'd like to quote from the essay you'll find a link to in my.sig:
In the passing generations we've forgotten things. We've forgotten the compromises we've made; we've forgotten the reasons we've made them. We're no longer poor. The machine on which I'm typing this - my personal machine, on my desk, used by no-one but me - has the processor power of slightly over six thousand DEC VAXes; it has the one hundred and sixty two thousand times as much core store as the ICL 1900 mainframe on which I learned Pascal. Yet both the VAX and the 1900 were powerful machines, capable of supporting dozens of users at the same time. Compared to each individual user of the VAX, of the 1900, I am now incalculably rich. Vastly. Incomprehensibly.
And it's not just me. With the exception of those poor souls writing embedded code for micro-controllers, every programmer now working has processor and store available to him which the designers of the languages and operating systems we still use could not even have dreamed of. UNIX was designed when 32 bit machines were new, when 16,384 bytes was a lot of memory and very expensive. VMS - what we now call 'Windows XP' - is only a few years younger.
The compromises of poverty are built into these operating systems, into our programming languages, into our brains as programmers; so deeply ingrained that we've forgotten that they are compromises, we've forgotten why we chose them. Like misers counting grains on the granary floor while outside the new crop is falling from the stalks for want of harvesting, we sit in the middle of great riches and behave as though we were destitute.
Yes, learning C, learning assembler, is learning how machines work at the metal. But to use that as an insight into how to build sophisticated software systems is to try to understand the structure of termite mounds by studying the musculature of a termite. The granularity is so wrong that you're not able to conceive the issues. It really doesn't matter except to those of us who write runtime systems how store is manipulated, what primitive operations are performed on the metal. The application layer programmer should describe his problem, not how to solve it. It's my job to give him a sufficiently rich notation to describe his problem easily and idiomatically, and to make sure that that notation is translated into the most efficient possible sequence of primitive operations. He shouldn't need to have any idea what I am doing underneath.
Granularity, abstraction, information hiding has been how we have leveraged programmer productivity successively over the sixty years we've now been building software, and I don't believe that the returns on raising the level of abstraction are yet reducing: we've still some way to go in
Just as an extra anecdote and illustration of what happens when such people finally get told about pointers (but still don't quite "get it"): one team's architect actually told everyone to use "Integer" instead of "int" in method definitions everywhere, because it's faster! See, it copies only a pointer instead of the whole int!
Yeah, that guy was quite a bit less than a Michelangelo.
Was he? You sure?
If that was his real reason then fair enough. But there are lots of valid reasons for choosing to use an 'everything is an object' style. It makes things a lot more orthogonal (although since Java 5 autoboxing has sort of fudged this issue).
It's really all information. Tool fetishism is a bore.
The real question to be asked is: how heavy of a run-time do I really want? The minimalist wrapper you have with C/C++, a medium-weight one as with a scripting language, or the 800lb gorilla of a JVM/CLR?
A Venn diagram of the choices would show _significant_ overlap.
Well said!
With the proviso that if you don't have a rich enough runtime, you're going to have to code those parts of a rich runtime environment that you need yourself, and although any general purpose runtime has lots of features which are not needed for any particular program, in general you're going to save a lot of time (and a lot of bugs) choosing a runtime which supports most of your needs.
Apart from anything else, hundreds of thousands of programs are testing the JVM (for example) every day - and doing different things with it. If there's a bug in it, it's going to be found quickly. If there's a bug in code that's custom-written for one particular project, it can lurk around for a long time before manifesting itself in some horrible way.
There's a trade off between producing tight, lightweight code with low overhead, and economically producing good quality systems. That tradeoff involves the right choice of runtime for the particular project.
But tool fetishism, and 'my language is better than your language' pissing matches, are, indeed, a bore.
C->C++->assembly (any ISA)->some functional language->some other language (Java, python, ruby, etc).
Assembly is necessary, to understand how a computer really works. Functional languages are good, just to know a completely different style. Some other language for breadth. Then the student can realise that everythin after asm was a waste of time, and return to C.
This is kind-of bollocks.
When I was a young programmer - which is about twenty-five years ago - the team I was on got a new ink-jet printer. It printed its own character set, we needed it to print bitmaps. The processor it used was one none of us had ever worked with before. One of the older members of the team - a guy called Chris Burton - took the spec sheet for the processor and the spec sheet for the printer home with him on the train, and came back the next day with the code for the new printer driver written in long hand, not in assembler mnemonics but in actual op-codes, in pencil on a pad of paper. It was burned on an EEPROM that day and drove the printers until that model became obsolete five years later - there were no bugs, it never needed fixing.
It should be said in passing that Chris had worked in his youth on the Manchester Mark One, and after he retired was part of the team that rebuilt Baby and got it running again.
I've always thought that was epic programming, a standard I'll never reach. But it's one particular layer on the stack. My job on that team was writing inference engines, and Chris was always really impressed by that. It's nearly thirty years since I touched any assembler and fifteen since I wrote anything serious in C. A modern computer system is way too complex for any single person to really understand, in depth, all the layers. I take what the silicon designers do as given, and likewise the microcode programmers. Right back in the early days of Linux I did fix issues in kernel code a couple of times but I wouldn't even try these days - the guys who do that are much more expert at it than I am. Likewise, I don't expect them to understand the compiler compilers that I write. It's a different layer on the stack.
I agree that you need to have a rough idea about how the whole stack works. But we no longer expect all computer science students to be able to wire up NAND gates from discrete valves or transistors. And although a computer scientist needs to know that there are primitive logic operations carried out on the metal, and that on top of that there are a stack of different software layers with real machine code on the bottom and a whole slew of intermediate code representations above that, I don't believe that it is any longer necessary for all students to be able to write a serious program in assembler.
Re:The best tools stay out of the way...
on
Goodbye Cruel Word
·
· Score: 1
Amen, brother. That's why I like to use sed and shell echos, pipes, and redirects to do my word processing.
Many a true word spoken in jest. My 'word processor' now consists of shell script which uses sed to convert my own very idiosyncratic markup into HTML, pipes that through tidy and then through an XSL transform which adds standard boilerplate headers as required and then through Prince to generate print-ready PDF.
Why?
First, it means I can use any text editor I like to edit my text (currently I use kate);
Second, it plays nice with CVS;
Third, I can define my own markup at any time;
Fourth, it saves distractions;
Fifth, it separated content from presentation, so that I can produce an editor's galley proof or a print-ready paperback from the same text.
OK, I accept this wouldn't suit everyone but it works for me.
McAfee is trying to abide by the terms of the GPL. The problem is simply that nobody knows what the terms of the GPL actually are. McAfee is simply acknowledging the risk that they got it wrong.
Everyone knows what the terms of the GPL actually are. It's an incredibly simple document, which you can read and understand in five minutes. Either they publish their source, or else they don't use GPL code. And if that means - which I do not believe - that that means they can't write a Linux kernel module, well, tough, they can't.
No. Because making an argument that most people would assume the worst, but that is technically true, is totally okay.
How is claiming that something is infringement while it is not 'technically true' ?
I agree that the defense should have spotted this, and should have dealt with it, but that doesn't change that someone has been lying in court, likely misdirecting the jurors on purpose, which in itself is a serious enough issue to deal with, unless you believe that a properly functioning legal systemn isn't very important.
Uhhhmmm, as a matter of interest, is this evidence which was given on oath?
"They have a very simple solution, then, don't they? Do their own graft, write their own damn software, and stop freeloading off the community."
Your understanding of the issues involved seems pretty close to zero. They are not "freeloading off the community", they are supporting Linux.
The problem is simply that in order to write software that interacts with Linux at the low level they need to interact, they need to use code that defines how Linux processes some things internally. There is no choice -- to support Linux, they need to use that code.
No, they are not 'supporting Linux'. Nothing in the McAfee statement says anything about Linux - the whole Linux angle is a fantasy dreamed up by trolls here on Slashdot.
McAfee do produce a 'virus scanner for Linux', but this is not 'supporting Linux', it's snake oil. It's blurb says:
McAfee LinuxShield(TM) offers continuous on-access scanning for superior protection from the growing number of viruses, worms, and other malicious code targeting Linux systems....
So how big is this 'growing number'? Null, nill, zilch, none, zero. No single Linux virus has ever been found in the wild. Which isn't surprising, given the heterogeneity of the Linux computing environment, the openness and general security of Linux kernel level code, and the practice of not allowing user-level code to run as root. So McAfee are selling a cure for a disease which does not exist. Oh - yes - the 'virus scanner for Linux' does scan for Windows viruses on Linux systems.
These people are people who make their living out of malicious software. If malicious software goes away, their business dies. So of course they're spreading FUD about open source software. You'd expect them to.
But even if all this were not so, even if McAfee's Linux products were actually useful for something, McAfee is a member of the Business Software Alliance, and have strong views on software piracy. They say, 'Software piracy is the illegal distribution and/or reproduction of software'. It is illegal to distribute GPL'd software without the full source code of what it is linked to. McAfee can't pick and choose which software the law applies to - either it applies to no software at all, or it applies to all software. If they are using GPL software without abiding by the terms of the license, then they are 'software pirates' (and on an epic scale). They cannot have it both ways.
McAfee's problem is that they will include linux kernel structures in their code in order to replace them in memory. This is really only necessary on windows where the necessary APIs dont exist but hey old dogs new trick.
That is certainly false. McAfee aren't making or selling kernel level Linux products (at least, as far as I know). They make anti virus systems, and Linux doesn't need anti-virus systems - and, indeed, one of the main reasons it doesn't is because the kernel is developed so publically and thus has relatively few vulnerabilities. The Linux kernel is a complete red herring here. If McAfee are abusing GPL code - and presumably they are, or they wouldn't worry about whether they were vulnerable - then it's almost certainly in a product that runs on Windows.
You would be mad to buy a closed source 'anti-virus' product for Linux which ran as root, never mind in the kernel. 'Anti-virus' is about security, and closed software just ain't secure.
You are seriously mistaken. You are assuming that it is company policy to inappropriately incorporate GPL'd code. It may be against policy but a programmer may get lazy and do it on his own. Hell, it could be a relatively honest mistake like confusing a GPL'd lib for a LGPL'd lib. A GPL related lawsuit would be an appropriate item in the risks section of an SEC filing.
If you don't have sufficient code review processes in place, and you don't know where your employees are copying code from, that's very much your problem. McAfee may be that unprofessional, but if they are they deserve everything that's coming to them.
If you mess with kernel support functions you have to use the GPL because the Linux kernel is GPL'd. That is what the GP's post is about.
Wrong
If you link against the Linux kernel (or part of it), then you have to use GPL. Very few programs do this. Even kernel modules do not have to do this, provided they use the correct API.
If you copy code from the Linux kernel, then you have to use the GPL. Incidentally, this applies even if you don't copy verbatim - if you copy the structure and then change variable and function names, you still have to use GPL.
But if you have a piece of code which you wrote in its entirety, and which is only linked against the Linux kernel when on Linux, then it only has to be GPL'd when actually linked to the Linux kernel. The version you ship on Windows or Mac OS X can be licensed any way you like.
Anyone who tells you different is just spreading FUD. Version Two of the GPL is a very simple document and is easy to read. It means just what it says, there's nothing complex behind it. Version Three is a little more prolix, but it still means just what it says. Go read it yourself; don't listen to people who are trying to mislead you.
Yes. And to correct the article, they aren't really worried about having to release code may "leave... products open to tampering", but rather, people might find blatantly obvious bugs or omissions with how they "protect" your computer. And then profit from it, either by writing rootkits or whatever that bypass their "protection" or by sueing them when they are infected by these rootkits.
They have a very simple solution, then, don't they? Do their own graft, write their own damn software, and stop freeloading off the community.
You are talking past what I said. I was not comparing Xerox with Apple, I was pointing out that Apple developed its own practical consumer technology, that for half the price delivered more usability - in the Lisa. And the Mac was another clear leap past that in terms of consumer usability and relevance.
Well, I do agree that the Mac was the first thing that delivered this stuff at a price people were willing to pay, but the Mac was dreadfully primitive compared to Lisa, and Lisa was primitive compared to the 1108 Dandelions and 1109 Dandetigers (and, later, 1186 Daybreaks) that I was playing with. The 1108 was the same physical hardware as Star but running Interlisp-D instead of Pilot; 1109 was an upgraded version which I don't think was ever sold with Pilot, and the 1132 Dorado was the same processor but with a colour graphics unit which I'm fairly sure had more processing power than the main processor. In all cases the processor was a custom bit-sliced processor implemented as four physical chips on a board; it was microcode programmable so that the Lisp machines, although on the same physical hardware, were different right down to machine-code level.
What Xerox was doing in its labs might have been real cool for the few hundred people who had a license to test drive it, but it had near zero impact on the rest of the world.
Agree.
If there was any real value in Xerox's UI, why couldn't the company sell it? It's not like they didn't try at all.
They failed to sell it because Xerox' main business was photocopiers, and Head Office saw the prospect of a paperless office as a threat, not an opportunity. The stuff that was developed at PARC failed commercially because Xerox did not want it to succeed.
If you look at the Star's interface, it's obvious that Apple invented a lot of valuable, original ideas. The Mac used direct manipulation with the mouse rather than clicking to select and then poking keyboard buttons, for example.
Star is not a good example of the Xerox PARC interface. Direct manipulation was common to most of 'em. In fact, I'm the Star had direct manipulation too - you certainly used drag and drop to file a document or to print it - but as I only used Stars a little so I couldn't swear how much direct manipulation they had. But we certainly had ubiquitous direct manipulation in all the Interlisp-D environments, and the Smalltalk people certainly did too.
There was also no overlapping window refresh and really thousands of other things we take for granted.
The original Star software had non-overlapping windows. But it had overlapping windows long before Steve Jobs saw it, and the Interlisp and Smalltalk environments always had overlapping windows.
It boils down to two products sold at different price points: one a success and one a failure.
You could probably also make a pretty nice car for $200,000 and a music player that exceeds the technology of the iPod for $4,000. You couldn't sell many of them though.
PARC was not intended to be a commercial operation; it was intended to be a research and development shop. Which it was. The fact that Xerox decided not to pursue a disruptive technology which threatened to sweep away their core business was a commercial decision - which turns out to have been a wrong one, but that's hindsight.
Yes, I agree, Apple got the modern GUI to market - at a price point people could afford - first. But innovation is not about getting it to market. Innovation is having the idea in the first place. And when you look at what the PARC team had in 1981 compared to what we have now, it's staggering how little innovation there's been since.
As for the Apple 'bought' the OS from Xerox idea, consider: Apple's 1983 Lisa was a huge leap past anything delivered by Xerox and was about half the price of the Star machines Xerox half-assedly tried to sell in the early 80s. The Mac was another big leap over the Lisa in UI, although it greatly simplified the sophistication of the underlying OS in order to deliver an environment that could run on consumer-priced hardware in 1984. Apple clearly led UI development through the mid 80s, and nothing was even close. This was because it had invested + $60 million into UI and OS development.
Speaking as someone who used and programmed for both the Xerox workstations and the original 128Kb Mac, don't talk complete bollocks. The Xerox stuff of the early 1980s was not merely streets more sophisticated, consistent and better integrated than Lisa, it was more sophisticated, consistent and better than anything we have now. Mac was not 'another big leap', it was a deliberately cut down version, because Apple could not get the (fairly sophisticated) Lisa software to run on hardware punters would actually pay for.
Try as William Gibson might to distance himself from Blade Runner's influence, the game adaptation of his seminal novel
I'm sure Phillip K. Dick will be glad to know that Gibson's now taking the heat for Blade Runner's influence! It must be a huge weight off his shoulders to know that some other Sci-Fi author gets to deal with his burdeon.
English comprehension was never your strong suite, was it? Neuromancer was, as advertised, written by... William Gibson (and, incidentally, won the Phillip K. Dick Award).
1997 called; it wants its irrelevant rant back. I am a linux geek, and I resist Windows as much as possible. But my job is not to find ways to get my email, contacts, calendar, etc. to sync with my PDA with some insane workaround. My PDA is a productivity item. If it doesn't "just work", it's wasting my time; why would I use it?
I, too, am an old UN*X geek working these days in a Windows environment, so I do understand where you're coming from. But the one thing I cannot do with Outlook/Exchange is make it produce competently formatted, RFC compliant email. As long as I use Outlook as my mail client, my email looks like the product of an incompetent; when communicating with my peers in other organisations I feel humiliated, I feel that I am not presenting myself well. It may be possible to force Outlook to produce properly formatted email, but, as you say, it's supposed to be a productivity application. If it doesn't "just work", it's wasting my time... The consequence is that if I need to communicate with people of my own level in other organisations, I phone them - I do not want them to see my email.
This is a crazy situation, which really gets me down. It doesn't matter how good the calendar add-on to Microsoft's email system is, if the email system cannot do its core job.
Uh, the New Testament wasn't authored in Hebrew - it was originally written in Greek, which was the common language of the day (owing to Alexandar the Great's March across most of Western Europe/Asia).
Saul of Tarsus was (probably) a native Greek speaker. Iesu ben Yussuf - the guy Christians refer to as 'Jesus' - was well educated and probably spoke some Greek. Everyone else in the New Testament story spoke Aramaic, a language closely related to Arabic; and that is almost certainly the language that Matthew's gospel (and Luke's and Mark's) was first written in.
The word used in Isaiah is probably best translated as young maiden. In using it to refer to the virgin birth Matthew translates it to Greek as virgin to go along with the rest of his account. It is obviously a more recent phenomenon than Isaiah, but it dates back to the first century - it isn't like this was a mistranslation from the middle ages. Matthew's intention of communicating that Mary was a virgin is very clear from the lengthy account of the whole story.
'Virgin' and 'maiden' are exact synonyms. 'Virgin' has latin roots, 'maiden' germanic; but they mean exactly the same thing. 'Girl' or 'Young woman' might be a different thing...
Yes, obviously, the early Christian writers were trying to make the strongest possible claims for Jesus, and, obviously, the fact that he seems to have been a bastard was an embarrassment they had to deal with.
You must be superhuman. Best cyclists can endure 200 wats for few hours. I could make 200w for 5 minutes (tested on ergometer).
Actually, you're well wrong. Cycling, like anything else, is about power to weight ratio. Lance Armstrong, in training, could output 6.8 watts per kilogramme, which on his body weight of 74Kg is just over 500 watts. Some of the big fast guys (Tom Boonen, Magnus Backstedt) can sustain really startling outputs for long periods of time. I have a friend who peaks around 600 watts and can sustain better than 400 all day; but on his 102Kg that's only 6 watts per Kg. That's strictly amateur - he's fast for us, but he couldn't compete with the pros.
There's nothing at all hard about 200 watts. Any club cyclist who can do a ten mile time trial at evens is sustaining 4.8 watts/Kg for half an hour. I can do that, and I'm probably old enough to be your grandfather. I weigh 82Kg, so for me that's 381 watts. And I can certainly do 200 watts (13.5mph on the flat, for someone my weight) for eight hours continuous without difficulty.
One solution could be to petition the government to upgrade the highway through town or build a ring road.
Another, considerably less friendly option, is to install one helluva hairpin turn in the main road. Easy enough for a passenger vehicle to navigate at playground speed, but impossible for a transport truck.
Maybe the ideal solution is to install a toll booth system. If a vehicle exceeds a certain weight (or physical dimension), they'll need to pay at the initial toll booth. Then, install a series of toll booths along the route with a police radar of some fashion. If the vehicle exceeds the posted speed limit, they need to pay another toll in order to proceed to the next segment.
In short order, one of two things will happen. The traffic will find an alternate route around the town, or the town will have earned enough money to build their own ring road.
The reason you don't understand the problem is that you have no history, and you have too much space.
My house was old when the United States Constitution was first drafted. Am I going to tear it down to make way for trucks? No. My village also doesn't have physical space for a ring road, without some major engineering - a bloody great bridge over the sea on one side, a tunnel or a massive cutting through the hills on the other. The solution isn't demolishing half the villages of Europe to make way for trucks, it's to ban the trucks from places they can't go. And, ideally, ban trucks of this size all together.
Sounds like a great opportunity for the law enforcement officers of Barrow Gurney to make some money issuing fines.
Except that no law is being broken.
It isn't against the law to walk on the ceiling, or to eat broken glass. It isn't against the law to take a 2.4 metre wide truck down a 1.8 metre wide street. We don't have laws (in this country, anyway) to protect people from their own stupidity.
My commute home takes me over a bridge which is 1.8 metres wide. Last night the traffic was queueing back half a mile from the bridge. I cycled past the queue to find a bunch of polis trying to deal with a truck and trailer that were too wide for the bridge and too big to turn in the road.
I thought as I watched them, 'ah, another victory for Tom Tom!'
Slashdot Mirror
CVTs don't work with higher power engines because they don't transmit a lot of torque. But they work well with smaller, low power engines. The Dutch DAF cars used them for years, and they were noted for there good fuel economy.
RTFA, will you! It already has passed all those tests, to full European standards.
Speaking as someone who drives an SUV, no vehicle with a rigid chassis (as most SUVs have) is going to be anything like as safe in a head-on collision as something with proper crumple zones.
Yup. Me.
I had a Citroen 2CV for years, and it was the best, most fun car I've ever had. This looks as it it's very much in the same spirit.
I agree that you need to have a rough idea about how the whole stack works. But we no longer expect all computer science students to be able to wire up NAND gates from discrete valves or transistors.
I agree a little more with the parent of your post because, I find that it's really important to be able to reason about what your code is *doing*. To reason code, one must understand what high-level language X is doing with it. A lot of mistakes that I see are made because people don't understand how their code is executing.
It doesn't take too much to learn. A bit of assembler, write some basic stuff, so that one can get the idea of it. Write a bit of C for a microcontroller, throw in a few pointers, so that one has a working understanding of stack/heap memory, function pointers and such. Only then will you be able to understand how the CLR works, how it tries to save you from resource leaks, and how you can still screw it all up.
Ignorance is not bliss when it comes to working in higher level abstractions. One needs to have some basic idea of what the abstraction is doing.
OK, I think you're wrong. And to explain why I think you're wrong I'd like to quote from the essay you'll find a link to in my .sig:
Yes, learning C, learning assembler, is learning how machines work at the metal. But to use that as an insight into how to build sophisticated software systems is to try to understand the structure of termite mounds by studying the musculature of a termite. The granularity is so wrong that you're not able to conceive the issues. It really doesn't matter except to those of us who write runtime systems how store is manipulated, what primitive operations are performed on the metal. The application layer programmer should describe his problem, not how to solve it. It's my job to give him a sufficiently rich notation to describe his problem easily and idiomatically, and to make sure that that notation is translated into the most efficient possible sequence of primitive operations. He shouldn't need to have any idea what I am doing underneath.
Granularity, abstraction, information hiding has been how we have leveraged programmer productivity successively over the sixty years we've now been building software, and I don't believe that the returns on raising the level of abstraction are yet reducing: we've still some way to go in
Yeah, that guy was quite a bit less than a Michelangelo.
Was he? You sure?
If that was his real reason then fair enough. But there are lots of valid reasons for choosing to use an 'everything is an object' style. It makes things a lot more orthogonal (although since Java 5 autoboxing has sort of fudged this issue).
It's really all information. Tool fetishism is a bore.
The real question to be asked is: how heavy of a run-time do I really want? The minimalist wrapper you have with C/C++, a medium-weight one as with a scripting language, or the 800lb gorilla of a JVM/CLR?
A Venn diagram of the choices would show _significant_ overlap.
Well said!
With the proviso that if you don't have a rich enough runtime, you're going to have to code those parts of a rich runtime environment that you need yourself, and although any general purpose runtime has lots of features which are not needed for any particular program, in general you're going to save a lot of time (and a lot of bugs) choosing a runtime which supports most of your needs.
Apart from anything else, hundreds of thousands of programs are testing the JVM (for example) every day - and doing different things with it. If there's a bug in it, it's going to be found quickly. If there's a bug in code that's custom-written for one particular project, it can lurk around for a long time before manifesting itself in some horrible way.
There's a trade off between producing tight, lightweight code with low overhead, and economically producing good quality systems. That tradeoff involves the right choice of runtime for the particular project.
But tool fetishism, and 'my language is better than your language' pissing matches, are, indeed, a bore.
Assembly is necessary, to understand how a computer really works. Functional languages are good, just to know a completely different style. Some other language for breadth. Then the student can realise that everythin after asm was a waste of time, and return to C.
This is kind-of bollocks.
When I was a young programmer - which is about twenty-five years ago - the team I was on got a new ink-jet printer. It printed its own character set, we needed it to print bitmaps. The processor it used was one none of us had ever worked with before. One of the older members of the team - a guy called Chris Burton - took the spec sheet for the processor and the spec sheet for the printer home with him on the train, and came back the next day with the code for the new printer driver written in long hand, not in assembler mnemonics but in actual op-codes, in pencil on a pad of paper. It was burned on an EEPROM that day and drove the printers until that model became obsolete five years later - there were no bugs, it never needed fixing.
It should be said in passing that Chris had worked in his youth on the Manchester Mark One, and after he retired was part of the team that rebuilt Baby and got it running again.
I've always thought that was epic programming, a standard I'll never reach. But it's one particular layer on the stack. My job on that team was writing inference engines, and Chris was always really impressed by that. It's nearly thirty years since I touched any assembler and fifteen since I wrote anything serious in C. A modern computer system is way too complex for any single person to really understand, in depth, all the layers. I take what the silicon designers do as given, and likewise the microcode programmers. Right back in the early days of Linux I did fix issues in kernel code a couple of times but I wouldn't even try these days - the guys who do that are much more expert at it than I am. Likewise, I don't expect them to understand the compiler compilers that I write. It's a different layer on the stack.
I agree that you need to have a rough idea about how the whole stack works. But we no longer expect all computer science students to be able to wire up NAND gates from discrete valves or transistors. And although a computer scientist needs to know that there are primitive logic operations carried out on the metal, and that on top of that there are a stack of different software layers with real machine code on the bottom and a whole slew of intermediate code representations above that, I don't believe that it is any longer necessary for all students to be able to write a serious program in assembler.
Many a true word spoken in jest. My 'word processor' now consists of shell script which uses sed to convert my own very idiosyncratic markup into HTML, pipes that through tidy and then through an XSL transform which adds standard boilerplate headers as required and then through Prince to generate print-ready PDF.
Why?
OK, I accept this wouldn't suit everyone but it works for me.
Everyone knows what the terms of the GPL actually are. It's an incredibly simple document, which you can read and understand in five minutes. Either they publish their source, or else they don't use GPL code. And if that means - which I do not believe - that that means they can't write a Linux kernel module, well, tough, they can't.
How is claiming that something is infringement while it is not 'technically true' ?
I agree that the defense should have spotted this, and should have dealt with it, but that doesn't change that someone has been lying in court, likely misdirecting the jurors on purpose, which in itself is a serious enough issue to deal with, unless you believe that a properly functioning legal systemn isn't very important.
Uhhhmmm, as a matter of interest, is this evidence which was given on oath?
Your understanding of the issues involved seems pretty close to zero. They are not "freeloading off the community", they are supporting Linux.
The problem is simply that in order to write software that interacts with Linux at the low level they need to interact, they need to use code that defines how Linux processes some things internally. There is no choice -- to support Linux, they need to use that code.
No, they are not 'supporting Linux'. Nothing in the McAfee statement says anything about Linux - the whole Linux angle is a fantasy dreamed up by trolls here on Slashdot.
McAfee do produce a 'virus scanner for Linux', but this is not 'supporting Linux', it's snake oil. It's blurb says:
So how big is this 'growing number'? Null, nill, zilch, none, zero. No single Linux virus has ever been found in the wild. Which isn't surprising, given the heterogeneity of the Linux computing environment, the openness and general security of Linux kernel level code, and the practice of not allowing user-level code to run as root. So McAfee are selling a cure for a disease which does not exist. Oh - yes - the 'virus scanner for Linux' does scan for Windows viruses on Linux systems.
These people are people who make their living out of malicious software. If malicious software goes away, their business dies. So of course they're spreading FUD about open source software. You'd expect them to.
But even if all this were not so, even if McAfee's Linux products were actually useful for something, McAfee is a member of the Business Software Alliance, and have strong views on software piracy. They say, 'Software piracy is the illegal distribution and/or reproduction of software'. It is illegal to distribute GPL'd software without the full source code of what it is linked to. McAfee can't pick and choose which software the law applies to - either it applies to no software at all, or it applies to all software. If they are using GPL software without abiding by the terms of the license, then they are 'software pirates' (and on an epic scale). They cannot have it both ways.
That is certainly false. McAfee aren't making or selling kernel level Linux products (at least, as far as I know). They make anti virus systems, and Linux doesn't need anti-virus systems - and, indeed, one of the main reasons it doesn't is because the kernel is developed so publically and thus has relatively few vulnerabilities. The Linux kernel is a complete red herring here. If McAfee are abusing GPL code - and presumably they are, or they wouldn't worry about whether they were vulnerable - then it's almost certainly in a product that runs on Windows.
You would be mad to buy a closed source 'anti-virus' product for Linux which ran as root, never mind in the kernel. 'Anti-virus' is about security, and closed software just ain't secure.
If you don't have sufficient code review processes in place, and you don't know where your employees are copying code from, that's very much your problem. McAfee may be that unprofessional, but if they are they deserve everything that's coming to them.
Wrong
If you link against the Linux kernel (or part of it), then you have to use GPL. Very few programs do this. Even kernel modules do not have to do this, provided they use the correct API.
If you copy code from the Linux kernel, then you have to use the GPL. Incidentally, this applies even if you don't copy verbatim - if you copy the structure and then change variable and function names, you still have to use GPL.
But if you have a piece of code which you wrote in its entirety, and which is only linked against the Linux kernel when on Linux, then it only has to be GPL'd when actually linked to the Linux kernel. The version you ship on Windows or Mac OS X can be licensed any way you like.
Anyone who tells you different is just spreading FUD. Version Two of the GPL is a very simple document and is easy to read. It means just what it says, there's nothing complex behind it. Version Three is a little more prolix, but it still means just what it says. Go read it yourself; don't listen to people who are trying to mislead you.
They have a very simple solution, then, don't they? Do their own graft, write their own damn software, and stop freeloading off the community.
Well, I do agree that the Mac was the first thing that delivered this stuff at a price people were willing to pay, but the Mac was dreadfully primitive compared to Lisa, and Lisa was primitive compared to the 1108 Dandelions and 1109 Dandetigers (and, later, 1186 Daybreaks) that I was playing with. The 1108 was the same physical hardware as Star but running Interlisp-D instead of Pilot; 1109 was an upgraded version which I don't think was ever sold with Pilot, and the 1132 Dorado was the same processor but with a colour graphics unit which I'm fairly sure had more processing power than the main processor. In all cases the processor was a custom bit-sliced processor implemented as four physical chips on a board; it was microcode programmable so that the Lisp machines, although on the same physical hardware, were different right down to machine-code level.
What Xerox was doing in its labs might have been real cool for the few hundred people who had a license to test drive it, but it had near zero impact on the rest of the world.Agree.
They failed to sell it because Xerox' main business was photocopiers, and Head Office saw the prospect of a paperless office as a threat, not an opportunity. The stuff that was developed at PARC failed commercially because Xerox did not want it to succeed.
If you look at the Star's interface, it's obvious that Apple invented a lot of valuable, original ideas. The Mac used direct manipulation with the mouse rather than clicking to select and then poking keyboard buttons, for example.Star is not a good example of the Xerox PARC interface. Direct manipulation was common to most of 'em. In fact, I'm the Star had direct manipulation too - you certainly used drag and drop to file a document or to print it - but as I only used Stars a little so I couldn't swear how much direct manipulation they had. But we certainly had ubiquitous direct manipulation in all the Interlisp-D environments, and the Smalltalk people certainly did too.
There was also no overlapping window refresh and really thousands of other things we take for granted.The original Star software had non-overlapping windows. But it had overlapping windows long before Steve Jobs saw it, and the Interlisp and Smalltalk environments always had overlapping windows.
It boils down to two products sold at different price points: one a success and one a failure.You could probably also make a pretty nice car for $200,000 and a music player that exceeds the technology of the iPod for $4,000. You couldn't sell many of them though.
PARC was not intended to be a commercial operation; it was intended to be a research and development shop. Which it was. The fact that Xerox decided not to pursue a disruptive technology which threatened to sweep away their core business was a commercial decision - which turns out to have been a wrong one, but that's hindsight.
Yes, I agree, Apple got the modern GUI to market - at a price point people could afford - first. But innovation is not about getting it to market. Innovation is having the idea in the first place. And when you look at what the PARC team had in 1981 compared to what we have now, it's staggering how little innovation there's been since.
Speaking as someone who used and programmed for both the Xerox workstations and the original 128Kb Mac, don't talk complete bollocks. The Xerox stuff of the early 1980s was not merely streets more sophisticated, consistent and better integrated than Lisa, it was more sophisticated, consistent and better than anything we have now. Mac was not 'another big leap', it was a deliberately cut down version, because Apple could not get the (fairly sophisticated) Lisa software to run on hardware punters would actually pay for.
I'm sure Phillip K. Dick will be glad to know that Gibson's now taking the heat for Blade Runner's influence! It must be a huge weight off his shoulders to know that some other Sci-Fi author gets to deal with his burdeon.
English comprehension was never your strong suite, was it? Neuromancer was, as advertised, written by... William Gibson (and, incidentally, won the Phillip K. Dick Award).
Phillip K. Dick wrote Do Androids Dream of Electric Sheep?, on which Blade Runner was based, and which Gibson claimed not to have read. OK?
I, too, am an old UN*X geek working these days in a Windows environment, so I do understand where you're coming from. But the one thing I cannot do with Outlook/Exchange is make it produce competently formatted, RFC compliant email. As long as I use Outlook as my mail client, my email looks like the product of an incompetent; when communicating with my peers in other organisations I feel humiliated, I feel that I am not presenting myself well. It may be possible to force Outlook to produce properly formatted email, but, as you say, it's supposed to be a productivity application. If it doesn't "just work", it's wasting my time... The consequence is that if I need to communicate with people of my own level in other organisations, I phone them - I do not want them to see my email.
This is a crazy situation, which really gets me down. It doesn't matter how good the calendar add-on to Microsoft's email system is, if the email system cannot do its core job.
Saul of Tarsus was (probably) a native Greek speaker. Iesu ben Yussuf - the guy Christians refer to as 'Jesus' - was well educated and probably spoke some Greek. Everyone else in the New Testament story spoke Aramaic, a language closely related to Arabic; and that is almost certainly the language that Matthew's gospel (and Luke's and Mark's) was first written in.
'Virgin' and 'maiden' are exact synonyms. 'Virgin' has latin roots, 'maiden' germanic; but they mean exactly the same thing. 'Girl' or 'Young woman' might be a different thing...
Yes, obviously, the early Christian writers were trying to make the strongest possible claims for Jesus, and, obviously, the fact that he seems to have been a bastard was an embarrassment they had to deal with.
Actually, you're well wrong. Cycling, like anything else, is about power to weight ratio. Lance Armstrong, in training, could output 6.8 watts per kilogramme, which on his body weight of 74Kg is just over 500 watts. Some of the big fast guys (Tom Boonen, Magnus Backstedt) can sustain really startling outputs for long periods of time. I have a friend who peaks around 600 watts and can sustain better than 400 all day; but on his 102Kg that's only 6 watts per Kg. That's strictly amateur - he's fast for us, but he couldn't compete with the pros.
There's nothing at all hard about 200 watts. Any club cyclist who can do a ten mile time trial at evens is sustaining 4.8 watts/Kg for half an hour. I can do that, and I'm probably old enough to be your grandfather. I weigh 82Kg, so for me that's 381 watts. And I can certainly do 200 watts (13.5mph on the flat, for someone my weight) for eight hours continuous without difficulty.
One solution could be to petition the government to upgrade the highway through town or build a ring road.
Another, considerably less friendly option, is to install one helluva hairpin turn in the main road. Easy enough for a passenger vehicle to navigate at playground speed, but impossible for a transport truck.
Maybe the ideal solution is to install a toll booth system. If a vehicle exceeds a certain weight (or physical dimension), they'll need to pay at the initial toll booth. Then, install a series of toll booths along the route with a police radar of some fashion. If the vehicle exceeds the posted speed limit, they need to pay another toll in order to proceed to the next segment.
In short order, one of two things will happen. The traffic will find an alternate route around the town, or the town will have earned enough money to build their own ring road.
The reason you don't understand the problem is that you have no history, and you have too much space.
My house was old when the United States Constitution was first drafted. Am I going to tear it down to make way for trucks? No. My village also doesn't have physical space for a ring road, without some major engineering - a bloody great bridge over the sea on one side, a tunnel or a massive cutting through the hills on the other. The solution isn't demolishing half the villages of Europe to make way for trucks, it's to ban the trucks from places they can't go. And, ideally, ban trucks of this size all together.
Except that no law is being broken.
It isn't against the law to walk on the ceiling, or to eat broken glass. It isn't against the law to take a 2.4 metre wide truck down a 1.8 metre wide street. We don't have laws (in this country, anyway) to protect people from their own stupidity.
Indeed.
My commute home takes me over a bridge which is 1.8 metres wide. Last night the traffic was queueing back half a mile from the bridge. I cycled past the queue to find a bunch of polis trying to deal with a truck and trailer that were too wide for the bridge and too big to turn in the road.
I thought as I watched them, 'ah, another victory for Tom Tom!'