``For the inevitable flamers among you, here's the short list of Windows apps I need, that Wine fails to support:
- Photoshop CS3 - Office 2007 - MSIE 6/7''
Some people have recommended getting a Mac for these. I feel obliged to point out that MSIE for Mac is not the same as IE for Windows. They have different features, and will render pages differently. What you want to test is how MSIE renders pages under Windows, so what you should test is exactly that.
I prefer to use Debian, but I do have a Windows license. I rarely use Windows, but I can if I have to. And it's a small cost in the grand scheme of things.
"... in recent decades especially since the Soviet success in launching the Sputnik satellite in 1957 the trend has been to create massive institutions that foster more collaboration and garner big chunks of funding."
Put that way, it sounds like a Good Thing. More collaboration? Good! Funding? Good! Especially if working in such an institution means the scientists don't have to spend as much time and energy securing funding, and can spend it on research instead.
``It means more people will view the web through a browser that is not IE. More people will use an office suite that supports ODF. More people will want music and videos without DRM. Even if not a single extra Linux app will be written (which I doubt), Linux as a platform will be supported better.''
And this is the really important news. There will be more support for standards and more interoperability. This enables choice. We're finally starting to see some competition in the consumer software field. And this benefits not just Linux and its followers, but everyone.
Governments would do well to realize that the power of their laws ultimately depends on people's willingness to follow them. If the law stands in the way of having information and works of art, only lawbreakers will have said information and works of art. But, as we've seen, tightening copyright doesn't actually stop dissemination of copyrighted works much. It does create more lawbreakers on a massive scale.
Lawsuits have been brought, people arrested in the middle of the night, and little children accused of felonies, and what is the result? More dissent and more organized resistance. People getting speeding tickets may not be enough to mobilize the masses, but criminal charges being brought against their daughters for seemingly innocuous activities will get a lot of soccer moms thinking. And there are a lot of soccer moms. A lot of people will be wondering if the government is acting in their best interests when faced with the lawsuits. And once they start wondering that about copyrights, the cat is out of the bag.
The bright side of this story is that it might finally wake up the masses and give politicians who act in the public interest a better chance.
``(What makes me bitter is failure of vendors to give adequate warning when software updates remove the capabilities of reading file formats that were formerly supported. I once verified that my new Mac could read my old MFS diskettes, and did not notice when a software update to the OS removed that capability. Microsoft was less than forthcoming when they removed the built-in ability of Excel to read Multiplan files).''
Technology skew is certainly a problem to be reckoned with, but it's not insoluble. Almost everything I have that is important to me is in simple file formats, mostly consisting of ASCII text. The rest is in formats that can be processed by software written in ASCII text. I'm sure ASCII text is going to be around for a long time. I'm sure my software is going to be around for a long time; it's all open-source and there are plenty of copies of it. It's built on Unix APIs, which easily go back 30 years and show no signs of going away. And all this can be run in a hardware emulator if, one day, compatible APIs do disappear.
All in all, I think technology skew is not the greatest of my worries. So long as I move my data off obsolescent hardware and onto new hardware, I don't think I have much to fear.
What does cause me to lose data is software bugs, faulty storage media, and my own mistakes. I've lost data through faulty filesystem drivers, I've lost backups because the media went bad, and I've lost data because I accidentally destroyed it before I had it backed up. More than data, though, I have lost interest. There is a lot of data that I could still access if I wanted to, but I don't want to and can't imagine that I ever will. Finally, both of these figures are dwarfed by the amount of data I actually use, from frequently to rarely. As long as I can maintain the balance the way it is now, I feel I'm doing a good job.
``Nature is reporting that bad brackets were replaced by the manufacturer... with identically bad brackets.''
Isn't that just purely amazing? A manufacturer who _knows_ the component is bad (because it needs replacement), and then replaces it with... the same thing with the same faults. That's just unethical. I hope they are suitably punished.
Also, you would have thought that, after sending a component back for replacement, the replacement would be tested to see if the problem had been fixed.
I came to this thread thinking to get some interesting ideas, but I think I'll offer some advice of my own, instead.
First of all, other than a lot of posters seem to think, I believe 11 to 14 year olds are probably developed enough to handle the same kind of languages that professionals use.
Secondly, I think it would be a bad idea to start them on an environment that you yourself don't know well. You want to be able to help them along and show them cool things that you've made, rather than go "Here's this thing for you to play with. I swear it's cool. Honest. But I myself won't touch it."
Thirdly, programming is not something you learn overnight, so it's important to keep learners motivated. I think one way to do that is to get them started on something that is easy to produce results with, and easy to get to something that looks like it could have been developed by a seasoned professional with.
So, without knowing what you yourself have expertise in (see the second point), what I would advise in general is: start with HTML. It's code. It's used by professionals. It's easy to learn. You can copy things you like from webpages. You can rapidly create something that looks solid, and you can rapidly get to the level that enables you to do so. Don't bother with IDEs or other tools: just a text editor to write the code in, and a browser (preferably a decent one) to view the results in. Add a few images and sprinkle in some CSS, and you can have a decent web page soon enough.
Of course, a web page by itself doesn't do anything. It's a nice way to communicate information or advertise oneself to the world (you can definitely impress your friends with it!), but we wanted programming, right? Well, the logical choice for that in the context of web pages is JavaScript. So teach them to make some nice interactive things: buttons that change the text color, a page that asks for a name to be entered and prints out a greeting with that name, maybe a tic-tac-toe game or something else that feels like an accomplishment, but isn't too much work. The most important thing here is: rewards must come quickly.
I've spent years and years just making web pages with JavaScript on them. Of course, all of that is browser side, so none of that actually had a lasting impact on the world. People thought it was impressive, I thought it was immensely cool, but, eventually, I did start to wonder how to do all the _other_ things that web sites do. That's where server-side programming comes in. When you submit an HTML form (or request a web page, for that matter), a request is made to the server. At a very fundamental level, the request is a bunch of parameters (key-value pairs and maybe some file data), and the server can do whatever the heck it wants with it. Nice servers send HTTP responses to clients, often including a page to be displayed by the browser. These pages can come from simple files, but they can also be generated by programs (CGI scripts). And that's where the fun starts. Because these programs can actually do anything you want. And you can write them in any language you want. And there are tons of libraries and frameworks that you can use to do so.
What I recommend, here, is keeping things simple. Start by picking a language, one that is simple to learn and doesn't come with a lot of unnecessary baggage. Use a language that is actually used out there. PHP, Perl, Python, and Ruby are probably good candidates. C and Java not so much - there are too many concepts involved in even a simple hello world program. Then start slowly. Don't introduce any frameworks. Just a program that outputs a simple HTML page (don't forget to output the headers, first, especially Content-Type). Then an HTML page that displays parameters that were submitted through a form. Then perhaps a simple game; a number or word guessing game or some such.
From there, the world is at your kids' feet. You can drag whatever you want into it: libraries that do interesting things, database access, perhaps an AJAX framework, the p
``Having a consistent interface to your data really is a wonderful thing. It means no hacks, no lists of utility functions; things just work as you would expect.''
This is really one of Ruby's greatest strenghts, and why I like it so much. It really feels like it was _designed_, rather than cobbled together.
On the other hand, the object.method notation isn't great for consistency. Invariably, you are going to get methods that don't rightly belong with one of the objects they affect. And then you have to wonder...was it "foo.method bar", "bar.method foo", "method bar, foo", or "SomeClass.method foo, bar"? I'm in favor of "function args" notation everywhere, with an optional namespace prefix so you can have multiple functions of the same name. The way Common Lisp has it.
I love Ruby, and I completely agree with you. Just because a newly discovered programming language is good, doesn't mean it's a good idea to go and rewrite your perfectly good code in it. It doesn't mean it's a Bad Thing, either, but, if the results are as you state (which I find easy to believe - ruby 1.8 _is_ dog slow), it's hard to argue that it is an improvement.
There is such a thing as the right tool for the job, and Ruby is not (with current implementations) the right tool for things that are CPU intensive and need to be fast. Unless you can isolate the parts that need to be fast and write them as extensions, which is easy to do and gives you the benefits of Ruby for most of your project, while still getting efficient code where it matters.
``This is causing many problems for Wikipedia administrators, because much of the UK vandalism now comes from a single IP, which, when blocked, affects potentially hundreds of thousands of anonymous users who intend no harm and are utterly confused as to why they are no longer able to edit.''
And here I thought that Wikipedia would be knowledgeable enough to know that authentication based on IP does not work. This has been known for...over a decade, I think. Authenticate users by...authenticating the _user_, and you might actually create a system that doesn't suffer from problems like the above.
People think this is funny? Objections about physical and mental issues among the elderly aside, I really think Medicare funds should be used to provide _medical care_ to those who need it, and not be spent on weapons.
Re:I wonder if the cd installer still sucks
on
FreeBSD 6.4 Released
·
· Score: 2, Insightful
Ahem. You not having encountered the problem doesn't make the parent's complaint any more or less valid.
Also, your attacks on "Linux installers" are uncalled for and off-topic. We're talking about the FreeBSD CD installer here.
I guess there is a part of your post that is insightful, but most of it is off-topic, and I would have modded it accordingly.
Not to stir up old debates again, but if you like Lisp, you might be better off going for Ruby than for Python. Coming from a Scheme background, I find Ruby to be the more elegant language.
Python is a great language, but my feeling about it is that it's designed to support one way of programming (and not even completely - it's sort of ambivalent between procedural and object-oriented). This is fine, and has the advantage off encouraging consistency among programs from different authors. However, I feel there is a better way: just give programmers building blocks and let the programmers compose them in any way they like. I feel Ruby does this, and the result is a language in which you can elegantly build your program in any way you like. In particular, I feel pure functional style is more natural in Ruby than in Python.
This is a disadvantage, but I feel it's offset by having a more relaxed trip. This is personal preference, though.
2. Safety risk if other drivers are mostly going above the speed limit (Atlanta highways, for example)
The safety risk is there, but only if the speed difference is so great that the speeding drivers from behind can't slow down in time. Since they are exceeding the speed limit, I hold that the blame for this risk fits squarely on their shoulders.
3. There'll always be people going ten under that you have to pass, and since you're such a good driver, you're not going to speed in the passing lane..causing severe traffic flow problems behind you.
That is to say, assuming there are people behind you who are exceeding the speed limit. The "traffic flow problems" you speak of are that they can not continue to travel at the speed they wanted to travel at, but instead have to stick to the speed limit. Which, actually, they are legally required to anyway. In the end, them having to slow down is caused as much by my sticking to the speed limit as by their exceeding it. And, well, they will just have to excuse me for not wanting to break the law so that they can go faster than what is allowed.
``4. If people can get away with it, people will do it. If there were snipers on every bridge with anti-material rifles that shot every car that was speeding, no one would speed. However, since a cop can pull over one person at a time, and often there aren't 40 cops at each speed trap...''
Yes. People will speed. I concede that.
``5. Most speed limits are WAY TOO LOW for their roads. Some highways engineers developed to be traveled on at 70MPH are marked down to 45MPH to improve revenue and 'safety'''
Agreed. If you want to raise those speed limits, I'm with you. If you want to change the system so that there is no more incentive to maximize income from traffic fines, I'm definitely with you.
Meanwhile, though, I will continue to comply with existing laws, and I won't feel a whit of sympathy for people who get annoyed because they want to exceed the speed limit and I don't. It's not my fault that the speed limits are what they are, and the speed difference between them and me is their own choice.
Having been in the States, I know you are right. They can and do put in place ridiculous and hard to notice restrictions, with the apparent aim of generating revenue. I believe the problem here is that the police actually _can_ generate revenue by dealing out tickets (and have to, according to what I've heard). This, of course, provides an incentive for them to fine people as much as possible as often as possible. I don't think that's a good idea, so I think the way the police are paid should be changed.
In the Netherlands, reporting the locations of speed traps isn't illegal, and all pop-music radio stations report the locations. There are even companies that have this as their core business.
``the ultimate speed trap repository available to you when you need it most while you're driving.''
Or you could just not drive so fast you would get a ticket. I know, I am totally out of touch with reality and my ideas are correspondingly crazy. But I'll happily take a few minutes extra travel time and have a relaxed ride, because I don't have to worry about law enforcement and other drivers slowing me down.
Browsers were quite a bit less complex during the first Browser Wars than they are now. Also, it wasn't just that Microsoft put out a good browser (really, it was, at the time), but also that they bundled it with their (then even more ubiquitous than now) operating systems, and that Netscape put out a number of, shall we say, ungood releases.
Now Microsoft faces competition in the browser market not just from other companies, but also from the open source community, which produces a number of good browsers. Also, the competing browsers often aren't as dependent on desktop web browser success as Netscape was: the open source browsers will exist as long as people are willing to maintain them, Apple has various income streams that don't depend on their browser, and Opera puts their browser on a lot more than Windows desktops alone.
Having a lot of money isn't necessarily going to speed up development. Developing complex software (which MS Internet Explorer is) takes time. You can use money to hire more developers, and that can speed things up, but, after a certain point, having more programmers will actually slow down development. You can use money to hire better programmers, but that has its limits, too. The same goes for buying faster hardware and better development tools. At some point, you just can't make things go faster, no matter how much money you have.
``What that should tell everybody is that MAYBE its not about "freedom".''
Of course it's not about freedom. The masses don't care about freedom to tinker. What they do care about is anyone's guess, but it's clear that Apple provides it. Perhaps years of marketing and raising brand awareness are paying off.
``Now I can compile the JVM to Flash and run my Java applets inside Flash - no more need to install those meddlesome Java plugins!''
People laugh about that, but consider this: how large is the Java plugin, and how large is the Flash plugin? And how long does it take to start a Flash file, and how long does it take to start a Java applet?
First, there is the issue of choice. Whoever makes the choice must bear the consequences. If the boot time is determined by company decisions, the company should pay. If the boot time is determined by what the employee does, the company shouldn't have to pay if the boot time is unreasonably long. You can't fault the company for a decision they didn't make, and you can't fault the employee for a decision they didn't make, either. Yet, you have to make one or both pay, either in time or in money.
But what is perhaps more important is that you need to consider how you want to treat each other. Are the company and its employees adversaries or are they working towards a common goal? Do you really want to be so anal about it that you want every minute of employee time accounted for, or, conversely, that you want every minute of your time paid? I would say that the company should be able to trust their employees. Otherwise, they shouldn't have hired them. So, trust your employees to report the time they've worked more or less correctly, and don't worry if they spent the time waiting for the computer to boot talking to a customer, discussing a problem with a colleague, or fetching a coffee that they would otherwise have fetched after booting the PC.
Slashdot Mirror
OSHI- you figured us out! We'll nuke the site from orbit, it's the only way to be sure!
Take off every "zig"!!
``For the inevitable flamers among you, here's the short list of Windows apps I need, that Wine fails to support:
- Photoshop CS3
- Office 2007
- MSIE 6/7''
Some people have recommended getting a Mac for these. I feel obliged to point out that MSIE for Mac is not the same as IE for Windows. They have different features, and will render pages differently. What you want to test is how MSIE renders pages under Windows, so what you should test is exactly that.
I prefer to use Debian, but I do have a Windows license. I rarely use Windows, but I can if I have to. And it's a small cost in the grand scheme of things.
"... in recent decades especially since the Soviet success in launching the Sputnik satellite in 1957 the trend has been to create massive institutions that foster more collaboration and garner big chunks of funding."
Put that way, it sounds like a Good Thing. More collaboration? Good! Funding? Good! Especially if working in such an institution means the scientists don't have to spend as much time and energy securing funding, and can spend it on research instead.
``It means more people will view the web through a browser that is not IE. More people will use an office suite that supports ODF. More people will want music and videos without DRM. Even if not a single extra Linux app will be written (which I doubt), Linux as a platform will be supported better.''
And this is the really important news. There will be more support for standards and more interoperability. This enables choice. We're finally starting to see some competition in the consumer software field. And this benefits not just Linux and its followers, but everyone.
My first thought when reading this was:
Governments would do well to realize that the power of their laws ultimately depends on people's willingness to follow them. If the law stands in the way of having information and works of art, only lawbreakers will have said information and works of art. But, as we've seen, tightening copyright doesn't actually stop dissemination of copyrighted works much. It does create more lawbreakers on a massive scale.
Lawsuits have been brought, people arrested in the middle of the night, and little children accused of felonies, and what is the result? More dissent and more organized resistance. People getting speeding tickets may not be enough to mobilize the masses, but criminal charges being brought against their daughters for seemingly innocuous activities will get a lot of soccer moms thinking. And there are a lot of soccer moms. A lot of people will be wondering if the government is acting in their best interests when faced with the lawsuits. And once they start wondering that about copyrights, the cat is out of the bag.
The bright side of this story is that it might finally wake up the masses and give politicians who act in the public interest a better chance.
``(What makes me bitter is failure of vendors to give adequate warning when software updates remove the capabilities of reading file formats that were formerly supported. I once verified that my new Mac could read my old MFS diskettes, and did not notice when a software update to the OS removed that capability. Microsoft was less than forthcoming when they removed the built-in ability of Excel to read Multiplan files).''
Technology skew is certainly a problem to be reckoned with, but it's not insoluble. Almost everything I have that is important to me is in simple file formats, mostly consisting of ASCII text. The rest is in formats that can be processed by software written in ASCII text. I'm sure ASCII text is going to be around for a long time. I'm sure my software is going to be around for a long time; it's all open-source and there are plenty of copies of it. It's built on Unix APIs, which easily go back 30 years and show no signs of going away. And all this can be run in a hardware emulator if, one day, compatible APIs do disappear.
All in all, I think technology skew is not the greatest of my worries. So long as I move my data off obsolescent hardware and onto new hardware, I don't think I have much to fear.
What does cause me to lose data is software bugs, faulty storage media, and my own mistakes. I've lost data through faulty filesystem drivers, I've lost backups because the media went bad, and I've lost data because I accidentally destroyed it before I had it backed up. More than data, though, I have lost interest. There is a lot of data that I could still access if I wanted to, but I don't want to and can't imagine that I ever will. Finally, both of these figures are dwarfed by the amount of data I actually use, from frequently to rarely. As long as I can maintain the balance the way it is now, I feel I'm doing a good job.
``Nature is reporting that bad brackets were replaced by the manufacturer... with identically bad brackets.''
Isn't that just purely amazing? A manufacturer who _knows_ the component is bad (because it needs replacement), and then replaces it with ... the same thing with the same faults. That's just unethical. I hope they are suitably punished.
Also, you would have thought that, after sending a component back for replacement, the replacement would be tested to see if the problem had been fixed.
I just don't have words anymore.
I came to this thread thinking to get some interesting ideas, but I think I'll offer some advice of my own, instead.
First of all, other than a lot of posters seem to think, I believe 11 to 14 year olds are probably developed enough to handle the same kind of languages that professionals use.
Secondly, I think it would be a bad idea to start them on an environment that you yourself don't know well. You want to be able to help them along and show them cool things that you've made, rather than go "Here's this thing for you to play with. I swear it's cool. Honest. But I myself won't touch it."
Thirdly, programming is not something you learn overnight, so it's important to keep learners motivated. I think one way to do that is to get them started on something that is easy to produce results with, and easy to get to something that looks like it could have been developed by a seasoned professional with.
So, without knowing what you yourself have expertise in (see the second point), what I would advise in general is: start with HTML. It's code. It's used by professionals. It's easy to learn. You can copy things you like from webpages. You can rapidly create something that looks solid, and you can rapidly get to the level that enables you to do so. Don't bother with IDEs or other tools: just a text editor to write the code in, and a browser (preferably a decent one) to view the results in. Add a few images and sprinkle in some CSS, and you can have a decent web page soon enough.
Of course, a web page by itself doesn't do anything. It's a nice way to communicate information or advertise oneself to the world (you can definitely impress your friends with it!), but we wanted programming, right? Well, the logical choice for that in the context of web pages is JavaScript. So teach them to make some nice interactive things: buttons that change the text color, a page that asks for a name to be entered and prints out a greeting with that name, maybe a tic-tac-toe game or something else that feels like an accomplishment, but isn't too much work. The most important thing here is: rewards must come quickly.
I've spent years and years just making web pages with JavaScript on them. Of course, all of that is browser side, so none of that actually had a lasting impact on the world. People thought it was impressive, I thought it was immensely cool, but, eventually, I did start to wonder how to do all the _other_ things that web sites do. That's where server-side programming comes in. When you submit an HTML form (or request a web page, for that matter), a request is made to the server. At a very fundamental level, the request is a bunch of parameters (key-value pairs and maybe some file data), and the server can do whatever the heck it wants with it. Nice servers send HTTP responses to clients, often including a page to be displayed by the browser. These pages can come from simple files, but they can also be generated by programs (CGI scripts). And that's where the fun starts. Because these programs can actually do anything you want. And you can write them in any language you want. And there are tons of libraries and frameworks that you can use to do so.
What I recommend, here, is keeping things simple. Start by picking a language, one that is simple to learn and doesn't come with a lot of unnecessary baggage. Use a language that is actually used out there. PHP, Perl, Python, and Ruby are probably good candidates. C and Java not so much - there are too many concepts involved in even a simple hello world program. Then start slowly. Don't introduce any frameworks. Just a program that outputs a simple HTML page (don't forget to output the headers, first, especially Content-Type). Then an HTML page that displays parameters that were submitted through a form. Then perhaps a simple game; a number or word guessing game or some such.
From there, the world is at your kids' feet. You can drag whatever you want into it: libraries that do interesting things, database access, perhaps an AJAX framework, the p
``Having a consistent interface to your data really is a wonderful thing. It means no hacks, no lists of utility functions; things just work as you would expect.''
This is really one of Ruby's greatest strenghts, and why I like it so much. It really feels like it was _designed_, rather than cobbled together.
On the other hand, the object.method notation isn't great for consistency. Invariably, you are going to get methods that don't rightly belong with one of the objects they affect. And then you have to wonder...was it "foo.method bar", "bar.method foo", "method bar, foo", or "SomeClass.method foo, bar"? I'm in favor of "function args" notation everywhere, with an optional namespace prefix so you can have multiple functions of the same name. The way Common Lisp has it.
I love Ruby, and I completely agree with you. Just because a newly discovered programming language is good, doesn't mean it's a good idea to go and rewrite your perfectly good code in it. It doesn't mean it's a Bad Thing, either, but, if the results are as you state (which I find easy to believe - ruby 1.8 _is_ dog slow), it's hard to argue that it is an improvement.
There is such a thing as the right tool for the job, and Ruby is not (with current implementations) the right tool for things that are CPU intensive and need to be fast. Unless you can isolate the parts that need to be fast and write them as extensions, which is easy to do and gives you the benefits of Ruby for most of your project, while still getting efficient code where it matters.
``This is causing many problems for Wikipedia administrators, because much of the UK vandalism now comes from a single IP, which, when blocked, affects potentially hundreds of thousands of anonymous users who intend no harm and are utterly confused as to why they are no longer able to edit.''
And here I thought that Wikipedia would be knowledgeable enough to know that authentication based on IP does not work. This has been known for...over a decade, I think. Authenticate users by...authenticating the _user_, and you might actually create a system that doesn't suffer from problems like the above.
People think this is funny? Objections about physical and mental issues among the elderly aside, I really think Medicare funds should be used to provide _medical care_ to those who need it, and not be spent on weapons.
Ahem. You not having encountered the problem doesn't make the parent's complaint any more or less valid.
Also, your attacks on "Linux installers" are uncalled for and off-topic. We're talking about the FreeBSD CD installer here.
I guess there is a part of your post that is insightful, but most of it is off-topic, and I would have modded it accordingly.
Not to stir up old debates again, but if you like Lisp, you might be better off going for Ruby than for Python. Coming from a Scheme background, I find Ruby to be the more elegant language.
Python is a great language, but my feeling about it is that it's designed to support one way of programming (and not even completely - it's sort of ambivalent between procedural and object-oriented). This is fine, and has the advantage off encouraging consistency among programs from different authors. However, I feel there is a better way: just give programmers building blocks and let the programmers compose them in any way they like. I feel Ruby does this, and the result is a language in which you can elegantly build your program in any way you like. In particular, I feel pure functional style is more natural in Ruby than in Python.
While your humor is appreciated, I feel compelled to point out that it should be
M-x knights-puzzle
Lisp doesn't use CamelCase.
Addressing your points one by one:
1. A few extra minutes of travel time.
This is a disadvantage, but I feel it's offset by having a more relaxed trip. This is personal preference, though.
2. Safety risk if other drivers are mostly going above the speed limit (Atlanta highways, for example)
The safety risk is there, but only if the speed difference is so great that the speeding drivers from behind can't slow down in time. Since they are exceeding the speed limit, I hold that the blame for this risk fits squarely on their shoulders.
3. There'll always be people going ten under that you have to pass, and since you're such a good driver, you're not going to speed in the passing lane..causing severe traffic flow problems behind you.
That is to say, assuming there are people behind you who are exceeding the speed limit. The "traffic flow problems" you speak of are that they can not continue to travel at the speed they wanted to travel at, but instead have to stick to the speed limit. Which, actually, they are legally required to anyway. In the end, them having to slow down is caused as much by my sticking to the speed limit as by their exceeding it. And, well, they will just have to excuse me for not wanting to break the law so that they can go faster than what is allowed.
``4. If people can get away with it, people will do it. If there were snipers on every bridge with anti-material rifles that shot every car that was speeding, no one would speed. However, since a cop can pull over one person at a time, and often there aren't 40 cops at each speed trap...''
Yes. People will speed. I concede that.
``5. Most speed limits are WAY TOO LOW for their roads. Some highways engineers developed to be traveled on at 70MPH are marked down to 45MPH to improve revenue and 'safety'''
Agreed. If you want to raise those speed limits, I'm with you. If you want to change the system so that there is no more incentive to maximize income from traffic fines, I'm definitely with you.
Meanwhile, though, I will continue to comply with existing laws, and I won't feel a whit of sympathy for people who get annoyed because they want to exceed the speed limit and I don't. It's not my fault that the speed limits are what they are, and the speed difference between them and me is their own choice.
Having been in the States, I know you are right. They can and do put in place ridiculous and hard to notice restrictions, with the apparent aim of generating revenue. I believe the problem here is that the police actually _can_ generate revenue by dealing out tickets (and have to, according to what I've heard). This, of course, provides an incentive for them to fine people as much as possible as often as possible. I don't think that's a good idea, so I think the way the police are paid should be changed.
In the Netherlands, reporting the locations of speed traps isn't illegal, and all pop-music radio stations report the locations. There are even companies that have this as their core business.
``the ultimate speed trap repository available to you when you need it most while you're driving.''
Or you could just not drive so fast you would get a ticket. I know, I am totally out of touch with reality and my ideas are correspondingly crazy. But I'll happily take a few minutes extra travel time and have a relaxed ride, because I don't have to worry about law enforcement and other drivers slowing me down.
Browsers were quite a bit less complex during the first Browser Wars than they are now. Also, it wasn't just that Microsoft put out a good browser (really, it was, at the time), but also that they bundled it with their (then even more ubiquitous than now) operating systems, and that Netscape put out a number of, shall we say, ungood releases.
Now Microsoft faces competition in the browser market not just from other companies, but also from the open source community, which produces a number of good browsers. Also, the competing browsers often aren't as dependent on desktop web browser success as Netscape was: the open source browsers will exist as long as people are willing to maintain them, Apple has various income streams that don't depend on their browser, and Opera puts their browser on a lot more than Windows desktops alone.
``perhaps humans are too strange to be completely understood after all.''
I'm sure of that, but the beauty is that you don't necessarily need to understand everything to come up with a working algorithm.
Having a lot of money isn't necessarily going to speed up development. Developing complex software (which MS Internet Explorer is) takes time. You can use money to hire more developers, and that can speed things up, but, after a certain point, having more programmers will actually slow down development. You can use money to hire better programmers, but that has its limits, too. The same goes for buying faster hardware and better development tools. At some point, you just can't make things go faster, no matter how much money you have.
``What that should tell everybody is that MAYBE its not about "freedom".''
Of course it's not about freedom. The masses don't care about freedom to tinker. What they do care about is anyone's guess, but it's clear that Apple provides it. Perhaps years of marketing and raising brand awareness are paying off.
``Now I can compile the JVM to Flash and run my Java applets inside Flash - no more need to install those meddlesome Java plugins!''
People laugh about that, but consider this: how large is the Java plugin, and how large is the Flash plugin? And how long does it take to start a Flash file, and how long does it take to start a Java applet?
I think there are two main issues here.
First, there is the issue of choice. Whoever makes the choice must bear the consequences. If the boot time is determined by company decisions, the company should pay. If the boot time is determined by what the employee does, the company shouldn't have to pay if the boot time is unreasonably long. You can't fault the company for a decision they didn't make, and you can't fault the employee for a decision they didn't make, either. Yet, you have to make one or both pay, either in time or in money.
But what is perhaps more important is that you need to consider how you want to treat each other. Are the company and its employees adversaries or are they working towards a common goal? Do you really want to be so anal about it that you want every minute of employee time accounted for, or, conversely, that you want every minute of your time paid? I would say that the company should be able to trust their employees. Otherwise, they shouldn't have hired them. So, trust your employees to report the time they've worked more or less correctly, and don't worry if they spent the time waiting for the computer to boot talking to a customer, discussing a problem with a colleague, or fetching a coffee that they would otherwise have fetched after booting the PC.