I don't agree with this blind assertion that the GPL is more "restrictive" than the BSD. Exactly who are we talking about? Sure, it can be a bit more complicated for a developer trying to work with code from different sources, but the people that matter are the users. With BSD licensing a middleman can take away rights from the end user.
The GPL is a way to try to make sure that the end user is more likely to have freedom.
Freedom is a more complex idea than just "anybody can do what they want". The ability to place constraints on others (which is what the BSD license allows, and which most commercial licenses actually do directly) results in a less free world when looked at from the point of view of the whole society.
Obviously the GPL is not perfect, but to call it 'corrupt'? Weird.
The BSD license is a compromise. A pragmatic one that allows the participation of 'amoral' corporate players, who don't care how restrictive they are, since all that matters is the bottom line.
It was almost like having 256 registers. Except that no-one ever saved them when they made a procedure call, so they ended up being 256 global integers, and you had to keep a list of what they were all used for so you didn't stomp on someone else's variables...
About as useful as the secondary register set in the Z80... (yeah, I know, fast interrupt handlers, etc, but still a waste of silicon).
I did like the Z80, but it was probably familiarity as much as anything; the newer processors (eg the Atmel AVR series) have much cleaner instructions sets.
Or a more specific hypothesis, that talking to a person who is not in the car requires the use of the parts of the brain that are required for spatial-temporal reasoning.
Needed? So why didn't the world fall apart when the fandangled realtime airline-pricing-optimization system got delivered two years late, way over budget, and full of bugs?
Twenty years after Dijkstra wrote this, the situation has not improved; arguably it is worse. Programming has changed from a mere craft to sorcery. How do we solve a problem now? Consult the oracle of google, randomly select an entry, and cut and paste some magic code or call some totemic library. Still doesn't work? Chant some testing incantations. After a while the customer decides that they've run out of time, and decides that near enough to spec is good enough (after all, the spec is not very formal, and can be stretched to fit the program!).
Sure, I'm exaggerating. But when nine out of ten 'software engineers' don't even know what an invariant is, there is a failure of education. Especially now, when most programmers are not coming out of elite universities (which still teach computer science), but out of tech courses.
No, we don't use formal principles to design our complex software projects. But it isn't because time doesn't permit. It is because we don't know how to.
We call it software engineering, but traditional engineering does work from formal principles, and then refines the parts of the construction. We know that doesn't work for software, because of orders of magnitude more complexity, and interactions between parts of the system. Symbolic digital computation is a paradigm shift.
Why does it matter? Because we aren't just talking airline systems. Twenty years ago the big deal was the missile defence system 'star wars', which was to be a larger software project than anything in existence at the time. The potential harm from the failure (at runtime) of such a project is not worth contemplating. Maybe your airline system is not important (!), but some of us write code that has life threatening consequences if it fails. So we welcome any advancement in the theory of programming, and in the teaching of that theory.
I haven't found the laptop keyboards to be great for a two year old; way too flimsy. I don't even let the older ones near the laptop; they just need to throw one tantrum and those keycaps would disintegrate. The typical desktop keyboard is fairly robust (as long as you keep food and drinks away from it, and discourage them from prying off the keys).
Another issue I have observed for young children (ie, <2yo) is that it takes them some time to realize the connection between moving the mouse and the motion of the cursor on the screen. They all seem to figure it out eventually, but I think they could have been using the computer much earlier if it had been a touch screen.
You've got to be pretty selective with software: do they use visual/aural cues (rather than written ones); how easy is it to exit the game, are they simple enough so that they don't frustrate the child; do they give hints; can you get stuck?
Some of the children's television websites have a good selection (BBC, Australian ABC, Children's Television Network, etc) covering different ages.
Of course, a computer screen isn't a substitute for tactile toys (building blocks, mud etc). But there is a middle road here.
Seriously though, new requirements that come in after a project is written are often hard to fit into the framework.
That doesn't necessarily mean always writing from scratch just so modifications can be made more easily. Quite often the advantages of a well written library (good coverage of a domain, a worked over design, tested by multiple users, and quick to incorporate) outweigh the ability to precisely meet each new requirement.
No point in perfectly meeting requirements if the project is never finished (conversely you could argue, no point in finishing if you can't fulfil the core functionality!).
If the taskbar is stuck on the side of the screen, press 1.
If the screen background says "Safe Mode", press 2.
If your computer starts up with seven beeps, press 3.
If Word is running extremely slowly, press 4.
If there is smoke coming out of the computer, press 5.
If the screen is bright blue, press 6.
If you can't work out how to turn off Windows, press 7.
If you have accidentally deleted the system directory, press 8.
If you have forgotten your password, press 9.
Otherwise hold the line and a bot will be with you shortly.
Yes, your second point is correct. Tablet recognition is not quite the same, because it typically records the strokes as they are made, rather than scanning the result. It has information about timing and sequence of actions, and can easily ignore pressure/width and small breaks.
An interesting experiment is to write characters on the tablet in unusual ways (eg, starting at the opposite end of a '7', drawing a letter in out-of-order segments, etc). It will look the same, but the recognition software will struggle to decipher it.
Yes, the non-competition clause here is surprisingly strong, if it really is "forever". In my (limited) experience, many employment agreements and contracts have only a restricted non-competition clause (typically two years after the end of the contract). The intent is to prevent competitors from head-hunting just so they can grab some IP. Though these days they do tend to cover work outside "normal" hours.
Yes, I'll second that. For example, a well written and generic sort routine will be called "sort", and will handle just about anything that is thrown at it. You write a call to sort, and it is redundant to have a comment that says "sort container X". But it makes a lot of sense to say why X is being sorted, or why at this point in the code, or how it fits into the bigger context.
The comments act to describe the bigger picture; like paragraph breaks in code to describe the semantics of a group of lines. Or abstracts summarizing a whole class, so that there is no need to read the entire code just to understand roughly how it works.
The primary reason we don't have the compiler checking our comments is not because we don't want to, but because we don't know how to. A little bit of English can convey a lot more meaning than a whole swathe of code, though less precisely. You can live and breathe code, and still not be aware of the programmer's intention without a little hint from the comments.
Every generation seems to make this assumption that code can be 'self-documenting'. Code can be a wonderfully precise way of describing some concepts, almost mathematical. But that doesn't mean that all concepts can be contained in a self-documenting piece of code.
You work on programs of hundreds of thousands of lines of code, and uncommented code really does become unmanageable. It isn't that hard; another 20% extra effort as the code is written...
Slashdot Mirror
I don't agree with this blind assertion that the GPL is more "restrictive" than the BSD. Exactly who are we talking about? Sure, it can be a bit more complicated for a developer trying to work with code from different sources, but the people that matter are the users. With BSD licensing a middleman can take away rights from the end user.
The GPL is a way to try to make sure that the end user is more likely to have freedom.
Freedom is a more complex idea than just "anybody can do what they want". The ability to place constraints on others (which is what the BSD license allows, and which most commercial licenses actually do directly) results in a less free world when looked at from the point of view of the whole society.
Obviously the GPL is not perfect, but to call it 'corrupt'? Weird.
The BSD license is a compromise. A pragmatic one that allows the participation of 'amoral' corporate players, who don't care how restrictive they are, since all that matters is the bottom line.
It was almost like having 256 registers. Except that no-one ever saved them when they made a procedure call, so they ended up being 256 global integers, and you had to keep a list of what they were all used for so you didn't stomp on someone else's variables...
About as useful as the secondary register set in the Z80... (yeah, I know, fast interrupt handlers, etc, but still a waste of silicon).
I did like the Z80, but it was probably familiarity as much as anything; the newer processors (eg the Atmel AVR series) have much cleaner instructions sets.
when you have a runny nose on a cold day.
We could just switch to Dutch, then we can all spell 'the' as 'de' and save heaps of letters!
and vegemite, don't forget 1 billion jars of vegemite :-)
Or a more specific hypothesis, that talking to a person who is not in the car requires the use of the parts of the brain that are required for spatial-temporal reasoning.
Now just to fit the MRI in the car.
Needed? So why didn't the world fall apart when the fandangled realtime airline-pricing-optimization system got delivered two years late, way over budget, and full of bugs?
Twenty years after Dijkstra wrote this, the situation has not improved; arguably it is worse. Programming has changed from a mere craft to sorcery. How do we solve a problem now? Consult the oracle of google, randomly select an entry, and cut and paste some magic code or call some totemic library. Still doesn't work? Chant some testing incantations. After a while the customer decides that they've run out of time, and decides that near enough to spec is good enough (after all, the spec is not very formal, and can be stretched to fit the program!).
Sure, I'm exaggerating. But when nine out of ten 'software engineers' don't even know what an invariant is, there is a failure of education. Especially now, when most programmers are not coming out of elite universities (which still teach computer science), but out of tech courses.
No, we don't use formal principles to design our complex software projects. But it isn't because time doesn't permit. It is because we don't know how to.
We call it software engineering, but traditional engineering does work from formal principles, and then refines the parts of the construction. We know that doesn't work for software, because of orders of magnitude more complexity, and interactions between parts of the system. Symbolic digital computation is a paradigm shift.
Why does it matter? Because we aren't just talking airline systems. Twenty years ago the big deal was the missile defence system 'star wars', which was to be a larger software project than anything in existence at the time. The potential harm from the failure (at runtime) of such a project is not worth contemplating. Maybe your airline system is not important (!), but some of us write code that has life threatening consequences if it fails. So we welcome any advancement in the theory of programming, and in the teaching of that theory.
guess you must be Gene XY.
I haven't found the laptop keyboards to be great for a two year old; way too flimsy. I don't even let the older ones near the laptop; they just need to throw one tantrum and those keycaps would disintegrate. The typical desktop keyboard is fairly robust (as long as you keep food and drinks away from it, and discourage them from prying off the keys).
Another issue I have observed for young children (ie, <2yo) is that it takes them some time to realize the connection between moving the mouse and the motion of the cursor on the screen. They all seem to figure it out eventually, but I think they could have been using the computer much earlier if it had been a touch screen.
You've got to be pretty selective with software: do they use visual/aural cues (rather than written ones); how easy is it to exit the game, are they simple enough so that they don't frustrate the child; do they give hints; can you get stuck?
Some of the children's television websites have a good selection (BBC, Australian ABC, Children's Television Network, etc) covering different ages.
Of course, a computer screen isn't a substitute for tactile toys (building blocks, mud etc). But there is a middle road here.
What about those ads that show cool froods downloading a movie in 4 seconds? Isn't that false advertising too?!
so, to fit with MS naming conventions, perhaps it should be called "Internet Explorer 2008".
> you... unplug its Linux kernel, and plug in a[n]... OpenSolaris kernel...
What happens?
Neither Linus nor Richard are happy.
...information activist wants to be free
though I guess you should leave out the line item about keeping up your slashdot account
Some interesting anecdotes here.
I liked the Cuban stories, of finding out who is the last to join and then just merging with the crowd.
Seems like Cubans use a linked list, Brits use a vector, and Indians use a heap!
Seriously though, new requirements that come in after a project is written are often hard to fit into the framework.
That doesn't necessarily mean always writing from scratch just so modifications can be made more easily. Quite often the advantages of a well written library (good coverage of a domain, a worked over design, tested by multiple users, and quick to incorporate) outweigh the ability to precisely meet each new requirement.
No point in perfectly meeting requirements if the project is never finished (conversely you could argue, no point in finishing if you can't fulfil the core functionality!).
you don't live in mountains in a country that ends with -istan by any chance?
how about uncooperative 2 year olds?
When it comes to a wired system and something goes wrong, it could be hardware noise, it could be programming bugs.
Nine times out of ten you'd have to place your money on a firmware fault.
(And I'm not casting aspersions on firmware engineers, myself included).
If the taskbar is stuck on the side of the screen, press 1.
If the screen background says "Safe Mode", press 2.
If your computer starts up with seven beeps, press 3.
If Word is running extremely slowly, press 4.
If there is smoke coming out of the computer, press 5.
If the screen is bright blue, press 6.
If you can't work out how to turn off Windows, press 7.
If you have accidentally deleted the system directory, press 8.
If you have forgotten your password, press 9.
Otherwise hold the line and a bot will be with you shortly.
Yes, your second point is correct. Tablet recognition is not quite the same, because it typically records the strokes as they are made, rather than scanning the result. It has information about timing and sequence of actions, and can easily ignore pressure/width and small breaks.
An interesting experiment is to write characters on the tablet in unusual ways (eg, starting at the opposite end of a '7', drawing a letter in out-of-order segments, etc). It will look the same, but the recognition software will struggle to decipher it.
Yes, the non-competition clause here is surprisingly strong, if it really is "forever". In my (limited) experience, many employment agreements and contracts have only a restricted non-competition clause (typically two years after the end of the contract). The intent is to prevent competitors from head-hunting just so they can grab some IP. Though these days they do tend to cover work outside "normal" hours.
while on the other hand, some of us sad people have gone through four different laptops while still using the same version of linux...
Exactly. They call it "creation of additional IP". Their word creation is newspeak for finding prior art that hasn't been codifed yet.
Yes, I'll second that. For example, a well written and generic sort routine will be called "sort", and will handle just about anything that is thrown at it. You write a call to sort, and it is redundant to have a comment that says "sort container X". But it makes a lot of sense to say why X is being sorted, or why at this point in the code, or how it fits into the bigger context.
The comments act to describe the bigger picture; like paragraph breaks in code to describe the semantics of a group of lines. Or abstracts summarizing a whole class, so that there is no need to read the entire code just to understand roughly how it works.
The primary reason we don't have the compiler checking our comments is not because we don't want to, but because we don't know how to. A little bit of English can convey a lot more meaning than a whole swathe of code, though less precisely. You can live and breathe code, and still not be aware of the programmer's intention without a little hint from the comments.
Every generation seems to make this assumption that code can be 'self-documenting'. Code can be a wonderfully precise way of describing some concepts, almost mathematical. But that doesn't mean that all concepts can be contained in a self-documenting piece of code.
You work on programs of hundreds of thousands of lines of code, and uncommented code really does become unmanageable. It isn't that hard; another 20% extra effort as the code is written...