You're blaming the wrong people. It's true that mass transit involves destroying parts of the city in order to make transportation available, but most forms of public transit don't.
What the Hell was that about???
P.S.: WRT mass transit. The city planners can't know ahead of time where the mass transit will need to go.
Of course, they can! It's analysis of resources, behavior of population, and trends in development. For the purpose of mass transit, collect data about population segments, employment in various kinds of businesses, distribution of them between locations, and you will get the demand for commute-related transportation. Whatever is not satisfied by public transit, falls on individual cars, or reduces availability of work. To reduce unemployment and/or resource usage, either move businesses, people, or public transportation infrastructure to whatever the simulation suggests.
To move people, develop new and fix existing housing instead of random sprawl, gentrification and decay into slums. To move businesses, change taxes and move infrastructure THEY rely on instead of pandering to whoever pays higher bribes. To move public transit, develop rail and bus lines based on the above mentioned models and not screams "But we don't want to have trains full of niggers going through OUR neighborhood!" from homeowners.
This is what "economists" are supposed to study when they are not busy selling some ideologically-based snake oil.
Maybe Elop is about to be fired or sued, or (not sure about laws in Finland but they can't be as executive-friendly as in US) charged with industrial sabotage or fraud?
Eliminating classes of bugs is a fool's errand -- the number of bugs produced by a programmer is constant per functionality implemented (or time for really bad programmers) and only depends on programmer's quality, so people will just write different, harder to find security bugs.
That is OK but in the real world a team will contain programmers of various skills. If they ever have to deal with your code you have to explain your interface to your co-workers. Even then they might use it in a way that you didn't think of. If you change it you have to re-explain it. If you change jobs the next person might not understand your interface, etc.
In other words, design and document your code, and make sure you won't have to redesign and re-document it every week.
Oh, wait, you can't write half-decent code in any language without following the same rule! What a coincidence!
It's just a growing frustration with having to read the constant, irrational "America bad - everyone else good" posts throughout the Internet by small, yet very vocal, group of people.
It's more like "US is so bad, everyone else is better by now".
You should stop being religious and start thinking for your self (if possible, something I seriously doubt). Just the fact that you implicitly equates "Open Source" with "Linux" above shows that you are a bigoted religious nutcase.
If it doesn't work on Linux, it is not written with any worthwhile goal in mind.
NTFS approach to the data reference/identifiers (what file names really are) is completely retarded because it is made entirely in assumption that such identifiers should contains anything human-readable, and will be handled in an ambiguous manner (the case, languages) instead of merely being human-identifiable names.
Filesystems' approach to data (any number of bytes with any content) is perfectly acceptable.
Like assembly, C forces you to think of a problem at the level of manipulating bits in memory and pushing them around, manually managing resources, etc.
C is nothing like assembly in that manner. Indeed it requires a programmer to think, how his data fits in memory. However any sane programmer creates an interface for that, and writes his data only through a safe interface he wrote once for any particular data type or store in his project. Considering that the number of "kinds of things" being stored is nearly constant for most of the project's lifetime, this only increases the amount of time and effort spent at the very beginning. This, contrary to the widespread myth, makes C great for large, long-running projects (ex: Linux kernel).
Assembly, on the other hand, provides no way to properly enforce types in interfaces created by a user, and contains no unified interface to memory allocation, thus preventing such approach from being applicable.
Solution: fire all frauds, leave professional programmers. Yes, it's possible to write software without buffer overflow and other glaring errors. If it wasn't, highways would by now be covered by two layers of cars disintegrated while driving.
If I am understanding your argument correctly, you are stating that a program must try to make sense of any input. I strenuously disagree.
No. A program should NOT try to "interpret" data that is supposed to be handled in an opaque manner. It should make sure that data, no matter what is in it, is always handled as just that, data. If it was received from the client, it must be treated as "tainted" -- that is, guaranteed to never appear at the input of any programming language's parser, be it SQL, Perl or machine code. For example, all SQL implementations support some way of declaring statements with no inline data. Use them, and supply data separately. This also improves performance because with proper implementation it reduces amount of parsing that database server performs at runtime.
The only problem is, there ARE people named Bobby Tables. "Filtering" is the wrong approach, the program must be able to handle any input in a safe manner, no matter how scary it looks like.
Really? C is a safer web language than Perl? Buffer overflows and all?
Yes. To have an exploitable buffer overflow, a programmer has to make a major mistake in the most fundamental area of programming. Interpreters come with vulnerabilities built-in, and often are written by opinionated douchebags, who care more about implementing their pet idea of "how software ought to be developed" than about quality of implementation.
Slashdot Mirror
You're blaming the wrong people. It's true that mass transit involves destroying parts of the city in order to make transportation available, but most forms of public transit don't.
What the Hell was that about???
P.S.: WRT mass transit. The city planners can't know ahead of time where the mass transit will need to go.
Of course, they can! It's analysis of resources, behavior of population, and trends in development. For the purpose of mass transit, collect data about population segments, employment in various kinds of businesses, distribution of them between locations, and you will get the demand for commute-related transportation. Whatever is not satisfied by public transit, falls on individual cars, or reduces availability of work. To reduce unemployment and/or resource usage, either move businesses, people, or public transportation infrastructure to whatever the simulation suggests.
To move people, develop new and fix existing housing instead of random sprawl, gentrification and decay into slums.
To move businesses, change taxes and move infrastructure THEY rely on instead of pandering to whoever pays higher bribes.
To move public transit, develop rail and bus lines based on the above mentioned models and not screams "But we don't want to have trains full of niggers going through OUR neighborhood!" from homeowners.
This is what "economists" are supposed to study when they are not busy selling some ideologically-based snake oil.
1. Eggs are not a service.
2. Food production does not have poverty of workers as a prerequisite.
Would your solution be to move the poor closer to services? That's been done, my friend. The results are not clearly superior to not doing so.
Solution: raise taxes until the results are superior.
Oh wow.
Most of the US, if not the world, does not have any form of public transport.
No, that's just US. In the rest of the world "city planner" and "fuckheaded asshole" are two different professions.
Congratulations, you are an idiot!
Theoretically, all you need is towing capacity, not return-to-ground, on the satellite interceptor: tow the satellite to the ISS
You mean, to US modules left hanging after everyone else disconnected them?
At least there's not a rope hanging from the ceiling.
No, that's just where the Sword of Damocles was before it fell on your predecessor.
Maybe Elop is about to be fired or sued, or (not sure about laws in Finland but they can't be as executive-friendly as in US) charged with industrial sabotage or fraud?
We've been using deduplication products, for backup purposes
Here is your problem. Backups should not be copied in myriads of instances and deduplicated on top of that insanity. They should be incremental.
lol wut
Eliminating classes of bugs is a fool's errand -- the number of bugs produced by a programmer is constant per functionality implemented (or time for really bad programmers) and only depends on programmer's quality, so people will just write different, harder to find security bugs.
That is OK but in the real world a team will contain programmers of various skills. If they ever have to deal with your code you have to explain your interface to your co-workers. Even then they might use it in a way that you didn't think of. If you change it you have to re-explain it. If you change jobs the next person might not understand your interface, etc.
In other words, design and document your code, and make sure you won't have to redesign and re-document it every week.
Oh, wait, you can't write half-decent code in any language without following the same rule! What a coincidence!
It's just a growing frustration with having to read the constant, irrational "America bad - everyone else good" posts throughout the Internet by small, yet very vocal, group of people.
It's more like "US is so bad, everyone else is better by now".
How can one make it any less likely?
Oh wow, for once roman_mir said something other than complete and ridiculous nonsense. Had he sold his account to follow his bright randroidian dream?
It may be "visually" identical to Thunderbird or gmail for all I care -- functionality still sucks ass compared to those interfaces.
I have news for you -- it's perfectly ok to have enemies and apply an effort to defeat them.
Really? So codeplex doesn't exist?
It does. And contains shit.
You should stop being religious and start thinking for your self (if possible, something I seriously doubt). Just the fact that you implicitly equates "Open Source" with "Linux" above shows that you are a bigoted religious nutcase.
If it doesn't work on Linux, it is not written with any worthwhile goal in mind.
NTFS approach to the data reference/identifiers (what file names really are) is completely retarded because it is made entirely in assumption that such identifiers should contains anything human-readable, and will be handled in an ambiguous manner (the case, languages) instead of merely being human-identifiable names.
Filesystems' approach to data (any number of bytes with any content) is perfectly acceptable.
Like assembly, C forces you to think of a problem at the level of manipulating bits in memory and pushing them around, manually managing resources, etc.
C is nothing like assembly in that manner. Indeed it requires a programmer to think, how his data fits in memory. However any sane programmer creates an interface for that, and writes his data only through a safe interface he wrote once for any particular data type or store in his project. Considering that the number of "kinds of things" being stored is nearly constant for most of the project's lifetime, this only increases the amount of time and effort spent at the very beginning. This, contrary to the widespread myth, makes C great for large, long-running projects (ex: Linux kernel).
Assembly, on the other hand, provides no way to properly enforce types in interfaces created by a user, and contains no unified interface to memory allocation, thus preventing such approach from being applicable.
Solution: fire all frauds, leave professional programmers. Yes, it's possible to write software without buffer overflow and other glaring errors. If it wasn't, highways would by now be covered by two layers of cars disintegrated while driving.
If I am understanding your argument correctly, you are stating that a program must try to make sense of any input. I strenuously disagree.
No. A program should NOT try to "interpret" data that is supposed to be handled in an opaque manner. It should make sure that data, no matter what is in it, is always handled as just that, data. If it was received from the client, it must be treated as "tainted" -- that is, guaranteed to never appear at the input of any programming language's parser, be it SQL, Perl or machine code. For example, all SQL implementations support some way of declaring statements with no inline data. Use them, and supply data separately. This also improves performance because with proper implementation it reduces amount of parsing that database server performs at runtime.
The only problem is, there ARE people named Bobby Tables. "Filtering" is the wrong approach, the program must be able to handle any input in a safe manner, no matter how scary it looks like.
Really? C is a safer web language than Perl? Buffer overflows and all?
Yes. To have an exploitable buffer overflow, a programmer has to make a major mistake in the most fundamental area of programming. Interpreters come with vulnerabilities built-in, and often are written by opinionated douchebags, who care more about implementing their pet idea of "how software ought to be developed" than about quality of implementation.