Anyway, I think IKEA chairs break too easily for SB's liking.
Hardly IKEA's fault if SB's too incompetent to follow the assembly instructions. Putting together IKEA stuff is simple enough for anyone who's ever played with LEGO and used a screwdriver...
my cat hid under the bed at almost 25 seconds into the New Year. Right after he heard the first of the fireworks. However he did restart normally about 22 minutes later after a soothing saucer of milk. I wonder if...
FYI, servers don't restart if you give them a saucer of milk, no matter how soothing it is.
The answer is not to shut down news on the net, it's to accept the fate that newsprint is dead.
The real issue is that almost all newspaper publishing in the US does not involve good journalism, and everyone knows it. I've seen it for myself in DC, Boston, Chicago, New Orleans and Seattle, all of which are large enough catchments to be able to support at least one major newspaper. If they had good journalists and good editors, stories that are worth reading would keep the readership interested, telling the readers stories that they felt they had to know.
In other parts of the world, newspapers are doing just fine and are turning into big providers of net content: it's just another medium for getting the "newspaper" (as a logical concept, not a physical entity) out. I suppose one of the things that defines any organization is how it responds to challenges. It's just a shame that for a "newspaper in the US", the operative word in this regard is "poorly".
Guarding against casual or thoughtless disclosure is a great mitigation; don't dismiss it because it doesn't solve the whole problem. No single thing will.
As long as you're just guarding against the casual screwup (i.e. the vastly most common case!) then solutions like AD RMS are fine. That's what they're there for, and the security people at MS would agree with me about this.
They're not intended to deal with malicious access, e.g. espionage. That's an entirely different problem, and much much harder.
Im kind of shocked that she did that.. but not in a geeky techy kind of way. I'm aamazd she could read the screen.
I've got a client who's in his sixties, and we had to configure the screen to 640x480 due to eyesight concerns. Even sitting at the screen 4 feet away, he cannot see text @ 1024x768.
That depends on the size of the font, not the resolution of the screen. A high-res screen with a large font works really nicely for legibility.
Oh, and the Mac GUI is fully scalable so pesky images aren't a problem either.
Who will be the first to post "ICodeInJavaWithClassesWithReallyReallyReallyLongNames.youIgnorantClod();" ?
80 column rule ftw.
Seriously, if you have a wide screen monitor, you *really* want the 80 column rule. It lets you put two source files side by side.
Then, if you get another monitor that lets you look at four source files at once. Or you can take one of those columns for documentation and another for your testing console; whatever suits.
If you're lucky enough to have 3 monitors, I envy you! (Four source files, the doc page and the console for you!)
Sure, just as soon as the Eds post the accepted/rejected ratio for Roland so we can see how it compares with the rest of us.
Hang about. Have you looked at the firehose? The amount of crap that gets submitted to the editors is just amazing. Roland seems to be good at writing just the right amount to make a good story, and so gets accepted frequently. Got a beef with it? Write plenty of good stories yourself. (It's very hard to do well; I've tried...)
The author needs to get out more. If they'd wanted real unexpected, going for Wine9+4i would have been a true eye-opener. It's certainly going to be complex enough...
I believe a thick sheet of perspex will help a lot there, assuming that the chair is a normal one going at speeds of up to a few tens of metres per second. If they're going faster than that, consider bullet-proof glass.
Seems to me a lot if not most first CS courses are taught at universities with large engineering programs. In these courses, CS students are by and large a minority. Most students are engineering majors who might take two programming courses, ever. Throwing Scheme at them to teach good coding practice in C or Java is like teaching someone to drive a semi by putting them on a scooter.
If they don't want to learn about CS, why are they taking a CS course at all? If they just need the credits, perhaps they should take something different.
FWIW, I went to a place that used ML as the first programming language. Now I didn't do that course (I was a physical sciences student at the time) so when I switched to CS I had to catch up while on vacation. ML has the property of being possible to learn from a book by just doing the examples on paper without any access to a computer at all: a purely mathematical understanding is all that's needed. Ended up doing my final year project in ML. (I wouldn't use it for anything real, of course: too difficult to control object identity. OCaml is a bit better, but identity control remains an issue; sometimes you really are better off going to Java or C++.)
There are no two things more opposite to each other than OOP and functional programming. Functional programming is about FUNCTIONS, which are those that return a value that is completely determined by their arguments, not depending on, or modifying, any state. OOP is all about calling METHODS, which have values that are determined by both the arguments and the state of the object they're called on, and often are meant to modify that state.
Not at all. I have used a pure functional OO language in the past (the name of which I forget) and what it did when you did an operation that would "modify the state" is return the new state as the result of the method. The same would be true for any language where all objects are immutable and variables are immutable.
"Functional" means that the answer to an operation is determined entirely by the arguments to the operation and the nature of the operation itself, and that the operation does not change the state. (Functional languages are usually written in pseudo-mathematical notation, but not always.) "Object-oriented" means that your values (often structured values) know exactly what operations can be performed upon them that don't just see the object as an abstract token, that they encapsulate that notion, and that the language is written in "subject verb" form, not "verb subject". (That last point is just syntactic, but important.) Those two are entirely orthogonal properties.
Obviously, you've mixed up "OO" and "Imperative OO"; imperative systems are all about state modification.
Now Microsoft is on the way down and Apple and Linux are moving up:
learn to write cross-platform applications
It isn't that hard, just pick a programming language that's available on both Linux and Windows and try to write programs that work on both Operating Systems. It can be done with some care!
Alas, it's not nearly as simple as that if you're doing GUI apps. The key problem is this: different platforms have different conventions. While there are similarities between typical Linux and Windows apps, they're not at all identical. And OSX apps really are different (and many users on that platform are incredibly picky).
There's at least one commercial app that I use (occasionally) that feels like a Linux app on all platforms, which isn't great on Windows and really sucks on OSX. I know it was written in Qt. I dare say that you could probably do a better job.
On the other hand, if you're developing non-GUI apps, there's probably only two key platforms to worry about: POSIX and Windows, with minor variations in each. Two is quite manageable, especially if you can wrap much of the platform-specific gunk into a small part of the program.
If it's in small chunks, but a lot of them, they you're screwed.
No, but you might need to use a custom allocator, and writing those to be performant is a fairly black art on any OS. (Yes, I've written such things for an application that had a non-standard memory usage pattern. The default "high-water mark" allocation strategy used by malloc() is much easier to work with!)
Yes, speed is nice, but if a language is error prone that matters too as far as productivity goes. Let's also not forget that Java at this point is about as fast as C++ (perhaps not considering class loading time).
Theoretically yes, but I work quite a bit with Java for a living and it's a PITA to actually get it to go that speed when dealing with real problems. Plus there's a real tendency among most of the Java world to do everything in Java. I prefer to use multiple languages: a low-level one for raw grunty power, and a high-level one for ease of sticking my high-power components together. To me, Java meets the model of a low-level language, and I prefer to use it as such.
OTOH, if you're doing webservices you're probably going to end up having Java or C# involved: the libraries there really are more advanced. They've had a lot of developer effort thrown at them, and not all of it was wasted.
The real measure of productivity is how quickly you can get to a working solution to the actual problem. Everything else is just messing around. So ease of development counts, as does stability, testing and debugging. Implementation performance doesn't always count so much; it depends on the situation (nobody is too bothered if you're a few microseconds faster at getting back to waiting for the user to click on a button). Just remember: the right tools for the job.
C/C++ are the languages you'd want to go for. They can do *everything*, have great support, are fast etc.
Let's be honest here. C and C++ are very fast indeed if you use them well (very little can touch them; most other languages are actually implemented in terms of them) but they're also very easy to use really badly. They're genuine professional power tools: they'll do what you ask them to really quickly, even if that is just to spin on the spot chopping peoples' legs off. Care required!
If you use a higher-level language (I prefer Tcl, but you might prefer Python, Perl, Ruby, Lua, Rexx, awk, bash, etc. - the list is huge) then you probably won't go as fast. But unless you're very good at C/C++ you'll go acceptably fast at a much earlier calendar date. It's just easier for most people to be productive in higher-level languages. Well, unless you're doing something where you have to be incredibly close to the metal like a device driver, but even then it's best to keep the amount of low-level code small and to try to get to use high-level things as soon as you can.
One technique that is used quite a bit, especially by really experienced developers, is to split the program up into components that are then glued together. You can then write the components in a low-level language if necessary, but use the far superior gluing capabilities of a high-level language effectively. I know many people are very productive doing this.
It's true that Moore actually said the transistor count doubles every 18 months.
The full statement of Moore's Law takes into account the price. What this means is that either you're getting faster processors, more processors, or cheaper processors. Or some combination of them, of course.
Expect to see more ubiquitous computing. Expect to see more parallel computing. Expect to see things get a bit faster. And expect to see programmers grumbling that the hardware people aren't doing their work for them, of course...
A well-tweaked system still has swap (in nontrivial amounts), but rarely uses it.
Not necessarily. Contrast with a supercomputer (which, trust me, is very well-tweaked indeed) which is typically run swapless. Of course, they're also adjusted to normally run at most one application at a time per CPU, and they will have limits set. They also usually work with large enough datasets that having lots of buffer cache doesn't help.
The problem I see without any sort of 'hosting' is that a project will 'die on the vine' as it were. Many projects are run by 1-5 people. When they loose interest (many do) as for many it is a hobby. What happens to that project? There would be no 'seed nodes' if EVERYONE is a peer. Why would I seed junk I never used and never will, or moved onto something else?
For open source it really isn't that difficult to find hosting: there are multiple providers out there. Putting everything distributed and P2P won't help very much. What really kills a project though is when nobody cares about it enough to look after it. If nobody cares, maybe it should die. If you care but you're letting it die, it's your fault!
P2P won't magically make a difference. People, developers, us! We will.
The whole point about this technology is you can use IM protocols or email, therefore you do not need to use expensive text. In the UK, 3 allows you to use Skype over 3G.
I was looking at that plan today (OK, I was bored and couldn't surf the net at the time) and it seems Skype's only enabled if you buy a certain amount of service per month. So maybe it saves you some, but it also saves 3 a lot as they don't have to pay so much for access to the long-distance infrastructure...
Knives and hacksaws are relativley common for substation thieves. Apparentley they think that their rubber soled shoes and rubber gloves can keep them safe against 115kV. Sometimes it does, but when it does not...it is ugly.
There's a simple way to deal with this. Up the voltage, and the problem becomes self-fixing. And it's not like those idiots can claim that nobody told them it was dangerous: high-voltage substations are well-signed already.
Driving in France (they drive on the right, we Brits drive on the left) is scary even before you contemplate the suicidally daring nature of the average French driver.
The left/right stuff mostly isn't too bad (and is actually easier in heavy traffic; all the other cars act as a great reminder) but you're right about French drivers. (For comparison, they're even nuttier than the Italians, Germans and Spaniards are only nutty on motorways, and Greeks are even madder than the French. Indeed, the only time I've ever been tempted to close my eyes and pray as a passenger was with a Greek driver...)
Indeed your metaphor stands. But remember, the climate is changing. The likelihood of car-sucking tornadoes it on the rise.
The metaphor stands even more strongly. Lashing the vehicle to the rafters wouldn't help with a car-sucking tornado since that'll take the rafters too. Similarly, AV on end systems is not helpful because it is trying to fix things up after it is rather too late; making sure that systems are Very Hard Targets (strongly locked down services, email filtering at the corporate/ISP level, that sort of thing) is far more effective.
Slashdot Mirror
Anyway, I think IKEA chairs break too easily for SB's liking.
Hardly IKEA's fault if SB's too incompetent to follow the assembly instructions. Putting together IKEA stuff is simple enough for anyone who's ever played with LEGO and used a screwdriver...
my cat hid under the bed at almost 25 seconds into the New Year. Right after he heard the first of the fireworks. However he did restart normally about 22 minutes later after a soothing saucer of milk. I wonder if ...
FYI, servers don't restart if you give them a saucer of milk, no matter how soothing it is.
start printing out all the useful info on wikipedia
That won't take very long...
The answer is not to shut down news on the net, it's to accept the fate that newsprint is dead.
The real issue is that almost all newspaper publishing in the US does not involve good journalism, and everyone knows it. I've seen it for myself in DC, Boston, Chicago, New Orleans and Seattle, all of which are large enough catchments to be able to support at least one major newspaper. If they had good journalists and good editors, stories that are worth reading would keep the readership interested, telling the readers stories that they felt they had to know.
In other parts of the world, newspapers are doing just fine and are turning into big providers of net content: it's just another medium for getting the "newspaper" (as a logical concept, not a physical entity) out. I suppose one of the things that defines any organization is how it responds to challenges. It's just a shame that for a "newspaper in the US", the operative word in this regard is "poorly".
Where/when did it all go wrong?
Guarding against casual or thoughtless disclosure is a great mitigation; don't dismiss it because it doesn't solve the whole problem. No single thing will.
As long as you're just guarding against the casual screwup (i.e. the vastly most common case!) then solutions like AD RMS are fine. That's what they're there for, and the security people at MS would agree with me about this.
They're not intended to deal with malicious access, e.g. espionage. That's an entirely different problem, and much much harder.
Im kind of shocked that she did that.. but not in a geeky techy kind of way. I'm aamazd she could read the screen.
I've got a client who's in his sixties, and we had to configure the screen to 640x480 due to eyesight concerns. Even sitting at the screen 4 feet away, he cannot see text @ 1024x768.
That depends on the size of the font, not the resolution of the screen. A high-res screen with a large font works really nicely for legibility.
Oh, and the Mac GUI is fully scalable so pesky images aren't a problem either.
Rails can only prosper from this (ugh, I hate how I'm phrasing this) 'merger'.
I agree. They can really leverage synergies and break down some silos with this.
They're not breaking down silos. They're just building a bigger silo.
Who will be the first to post "ICodeInJavaWithClassesWithReallyReallyReallyLongNames.youIgnorantClod();" ?
80 column rule ftw.
Seriously, if you have a wide screen monitor, you *really* want the 80 column rule. It lets you put two source files side by side.
Then, if you get another monitor that lets you look at four source files at once. Or you can take one of those columns for documentation and another for your testing console; whatever suits.
If you're lucky enough to have 3 monitors, I envy you! (Four source files, the doc page and the console for you!)
Sure, just as soon as the Eds post the accepted/rejected ratio for Roland so we can see how it compares with the rest of us.
Hang about. Have you looked at the firehose? The amount of crap that gets submitted to the editors is just amazing. Roland seems to be good at writing just the right amount to make a good story, and so gets accepted frequently. Got a beef with it? Write plenty of good stories yourself. (It's very hard to do well; I've tried...)
FTA:
The author needs to get out more. If they'd wanted real unexpected, going for Wine9+4i would have been a true eye-opener. It's certainly going to be complex enough...
No, just flying chairs
There really should be a screen saver for that.
I believe a thick sheet of perspex will help a lot there, assuming that the chair is a normal one going at speeds of up to a few tens of metres per second. If they're going faster than that, consider bullet-proof glass.
Seems to me a lot if not most first CS courses are taught at universities with large engineering programs. In these courses, CS students are by and large a minority. Most students are engineering majors who might take two programming courses, ever. Throwing Scheme at them to teach good coding practice in C or Java is like teaching someone to drive a semi by putting them on a scooter.
If they don't want to learn about CS, why are they taking a CS course at all? If they just need the credits, perhaps they should take something different.
FWIW, I went to a place that used ML as the first programming language. Now I didn't do that course (I was a physical sciences student at the time) so when I switched to CS I had to catch up while on vacation. ML has the property of being possible to learn from a book by just doing the examples on paper without any access to a computer at all: a purely mathematical understanding is all that's needed. Ended up doing my final year project in ML. (I wouldn't use it for anything real, of course: too difficult to control object identity. OCaml is a bit better, but identity control remains an issue; sometimes you really are better off going to Java or C++.)
There are no two things more opposite to each other than OOP and functional programming. Functional programming is about FUNCTIONS, which are those that return a value that is completely determined by their arguments, not depending on, or modifying, any state. OOP is all about calling METHODS, which have values that are determined by both the arguments and the state of the object they're called on, and often are meant to modify that state.
Not at all. I have used a pure functional OO language in the past (the name of which I forget) and what it did when you did an operation that would "modify the state" is return the new state as the result of the method. The same would be true for any language where all objects are immutable and variables are immutable.
"Functional" means that the answer to an operation is determined entirely by the arguments to the operation and the nature of the operation itself, and that the operation does not change the state. (Functional languages are usually written in pseudo-mathematical notation, but not always.) "Object-oriented" means that your values (often structured values) know exactly what operations can be performed upon them that don't just see the object as an abstract token, that they encapsulate that notion, and that the language is written in "subject verb" form, not "verb subject". (That last point is just syntactic, but important.) Those two are entirely orthogonal properties.
Obviously, you've mixed up "OO" and "Imperative OO"; imperative systems are all about state modification.
Now Microsoft is on the way down and Apple and Linux are moving up:
learn to write cross-platform applications
It isn't that hard, just pick a programming language that's available on both Linux and Windows and try to write programs that work on both Operating Systems. It can be done with some care!
Alas, it's not nearly as simple as that if you're doing GUI apps. The key problem is this: different platforms have different conventions. While there are similarities between typical Linux and Windows apps, they're not at all identical. And OSX apps really are different (and many users on that platform are incredibly picky).
There's at least one commercial app that I use (occasionally) that feels like a Linux app on all platforms, which isn't great on Windows and really sucks on OSX. I know it was written in Qt. I dare say that you could probably do a better job.
On the other hand, if you're developing non-GUI apps, there's probably only two key platforms to worry about: POSIX and Windows, with minor variations in each. Two is quite manageable, especially if you can wrap much of the platform-specific gunk into a small part of the program.
If it's in small chunks, but a lot of them, they you're screwed.
No, but you might need to use a custom allocator, and writing those to be performant is a fairly black art on any OS. (Yes, I've written such things for an application that had a non-standard memory usage pattern. The default "high-water mark" allocation strategy used by malloc() is much easier to work with!)
Yes, speed is nice, but if a language is error prone that matters too as far as productivity goes. Let's also not forget that Java at this point is about as fast as C++ (perhaps not considering class loading time).
Theoretically yes, but I work quite a bit with Java for a living and it's a PITA to actually get it to go that speed when dealing with real problems. Plus there's a real tendency among most of the Java world to do everything in Java. I prefer to use multiple languages: a low-level one for raw grunty power, and a high-level one for ease of sticking my high-power components together. To me, Java meets the model of a low-level language, and I prefer to use it as such.
OTOH, if you're doing webservices you're probably going to end up having Java or C# involved: the libraries there really are more advanced. They've had a lot of developer effort thrown at them, and not all of it was wasted.
The real measure of productivity is how quickly you can get to a working solution to the actual problem. Everything else is just messing around. So ease of development counts, as does stability, testing and debugging. Implementation performance doesn't always count so much; it depends on the situation (nobody is too bothered if you're a few microseconds faster at getting back to waiting for the user to click on a button). Just remember: the right tools for the job.
In case you didn't catch the reference:
Thanks. I didn't feel like googling.
C/C++ are the languages you'd want to go for. They can do *everything*, have great support, are fast etc.
Let's be honest here. C and C++ are very fast indeed if you use them well (very little can touch them; most other languages are actually implemented in terms of them) but they're also very easy to use really badly. They're genuine professional power tools: they'll do what you ask them to really quickly, even if that is just to spin on the spot chopping peoples' legs off. Care required!
If you use a higher-level language (I prefer Tcl, but you might prefer Python, Perl, Ruby, Lua, Rexx, awk, bash, etc. - the list is huge) then you probably won't go as fast. But unless you're very good at C/C++ you'll go acceptably fast at a much earlier calendar date. It's just easier for most people to be productive in higher-level languages. Well, unless you're doing something where you have to be incredibly close to the metal like a device driver, but even then it's best to keep the amount of low-level code small and to try to get to use high-level things as soon as you can.
One technique that is used quite a bit, especially by really experienced developers, is to split the program up into components that are then glued together. You can then write the components in a low-level language if necessary, but use the far superior gluing capabilities of a high-level language effectively. I know many people are very productive doing this.
It's true that Moore actually said the transistor count doubles every 18 months.
The full statement of Moore's Law takes into account the price. What this means is that either you're getting faster processors, more processors, or cheaper processors. Or some combination of them, of course.
Expect to see more ubiquitous computing. Expect to see more parallel computing. Expect to see things get a bit faster. And expect to see programmers grumbling that the hardware people aren't doing their work for them, of course...
A well-tweaked system still has swap (in nontrivial amounts), but rarely uses it.
Not necessarily. Contrast with a supercomputer (which, trust me, is very well-tweaked indeed) which is typically run swapless. Of course, they're also adjusted to normally run at most one application at a time per CPU, and they will have limits set. They also usually work with large enough datasets that having lots of buffer cache doesn't help.
The problem I see without any sort of 'hosting' is that a project will 'die on the vine' as it were. Many projects are run by 1-5 people. When they loose interest (many do) as for many it is a hobby. What happens to that project? There would be no 'seed nodes' if EVERYONE is a peer. Why would I seed junk I never used and never will, or moved onto something else?
For open source it really isn't that difficult to find hosting: there are multiple providers out there. Putting everything distributed and P2P won't help very much. What really kills a project though is when nobody cares about it enough to look after it. If nobody cares, maybe it should die. If you care but you're letting it die, it's your fault!
P2P won't magically make a difference. People, developers, us! We will.
The whole point about this technology is you can use IM protocols or email, therefore you do not need to use expensive text. In the UK, 3 allows you to use Skype over 3G.
I was looking at that plan today (OK, I was bored and couldn't surf the net at the time) and it seems Skype's only enabled if you buy a certain amount of service per month. So maybe it saves you some, but it also saves 3 a lot as they don't have to pay so much for access to the long-distance infrastructure...
Knives and hacksaws are relativley common for substation thieves. Apparentley they think that their rubber soled shoes and rubber gloves can keep them safe against 115kV. Sometimes it does, but when it does not...it is ugly.
There's a simple way to deal with this. Up the voltage, and the problem becomes self-fixing. And it's not like those idiots can claim that nobody told them it was dangerous: high-voltage substations are well-signed already.
Driving in France (they drive on the right, we Brits drive on the left) is scary even before you contemplate the suicidally daring nature of the average French driver.
The left/right stuff mostly isn't too bad (and is actually easier in heavy traffic; all the other cars act as a great reminder) but you're right about French drivers. (For comparison, they're even nuttier than the Italians, Germans and Spaniards are only nutty on motorways, and Greeks are even madder than the French. Indeed, the only time I've ever been tempted to close my eyes and pray as a passenger was with a Greek driver...)
Indeed your metaphor stands. But remember, the climate is changing. The likelihood of car-sucking tornadoes it on the rise.
The metaphor stands even more strongly. Lashing the vehicle to the rafters wouldn't help with a car-sucking tornado since that'll take the rafters too. Similarly, AV on end systems is not helpful because it is trying to fix things up after it is rather too late; making sure that systems are Very Hard Targets (strongly locked down services, email filtering at the corporate/ISP level, that sort of thing) is far more effective.