Cars created jobs long term. Many buggy repair places and horse growers were very upset and predicted gloom too!
But one could see the car industry as a likely source of new jobs to replace the horse jobs. We don't have anything equivalent in proportion.
A robot may replace 10 jobs for every 1 bot repair or design job it creates. (And they may soon be able to fix themselves.) Houston, we have a ratio problem. As somebody pointed out, industrial-age improvements magnified human ability, rather than outright replaced humans.
Perhaps we are just not spotting the new replacement jobs equivalent to horse-to-cars, but after bringing up this issue many times, nobody else has spotted it either.
Let's see if 20 years from now we slap ourselves on the forehead and say, "There it is, the Magic Gap! So obvious in hindsight, how could I be so dense! We are all.....belly dancers!"
trend is towards more and more defective items being replaced, not repaired
It's what auto-mechanics do more and more of. Read a trouble code, the screen brings up the part info, punch the order button connected to the local warehouse, a paid driver delivers it, mechanic snaps it in plus a couple of screws.
Even plumbing is becoming like that: the plumber swapped a hot/cold regulator module out for a new module in our house. It was a little tricky to snap in place, though, and that's where skill comes in. (My state regulates the hot/cold regulator design per "anti-scalding", for good or bad.)
Either bots will get better at snapping in the replacement modules, or the designs will be simplified enough for bot-enabled snapping in, at least for industrial machinery or heavily watched industries like cars.
that the general population starts to starve results in the leaders and top 1% getting their heads cut off. Never underestimate the power of an entire population with nothing to lose. Some of the rich people realize this, others don't...[emph. added]
I'd like to see clear(er) written guidelines for how say customer data should be cared for. And because their may be valid reasons to deviate from the guidelines, perhaps request that the reason for the deviations be written down by the organization and supplied on request to the FTC.
If you bring suitability into this then we could potentially do a lot of slicing and dicing* of the statistics. JavaScript is not suited to be a systems software language for building GUI engines, for example, but has ended up that way through historical accidents.
I would call that "culturally insensitive" perhaps, but NOT "racism". The R word is used too often. That joke is not demeaning in any definitive or clear sense. If I had implied that kind of food was dangerous or foul, I could see a real reason to complain.
I don't see associating the USA with hamburgers or cowboys offensive in any way to USA citizens unless negative traits were implied to be associated with them, such as obesity (burger) or excess bravado (cowboy).
I see 3 possible levels of association:
1. Associating situations with an ethnic trait or convention 2. Demeaning of an ethnic trait or convention 3. Demeaning of an ethnic group directly ("the X people are bad").
To be on the safe side, we could say "never do #1", but that's PC overkill. If I were an international diplomat, yes #1 probably should be ruled out. But, it's slashdot; we should be able to have a little bit of fun.
If it were American scientists and some Chinese made hamburger jokes, would it be "racist"? I don't know what the exact algorithm/formula is for determining "racism".
They seem implemented with arbitrary and inconsistent limits or usage steps per OS or file-system version. This typically makes any product that uses them married to a platform. It will probably require a "blockbuster" product to make anyone care enough to clean them up.
If file systems allowed arbitrary attributes per folder/file, then file systems could serve as both CMS's and light-duty CRUD storage. Most intranet CMS content is just lists of documents and links, with a few notes. They could be queried via SQL or an SQL-like language[1], along with the usual file-oriented techniques.
In addition to the arbitrary attributes, a set of common attributes would be reserved, at least by convention:
* title (file/folder name) * synopsis * content (file bytes) * type (type of content, perhaps by extension) * thumbnail (or icon) * create-date (date/time) * modif-date * orig-author (writer user name) * modif-author (who changed it) * sequence (preferred ordering [2]) * hidden (internal or system files/rows)
Conventions for display preferences and perhaps an HTML template(s) per folder or folder groups[3] could also be defined as part of the convention.
And perhaps per-folder[3] settings can enforce certain attributes or constraints, such as making synopsis required, for example.
Think about it: a flexible data tool without totally reinventing the wheel. We just soup-up existing file systems (or at least file conventions). Something is more likely to be accepted if it's similar to familiar tools--file systems and RDBMS in this case.
[1] Comparing operations may have to be more type-explicit if using dynamic or "indicator-free" types.
[2] Ordering by "convention" attributes (above) would typically be available, but sometimes the author wants explicit control of ordering
[3] Folders could perhaps define a path and/or grouping so that they can "inherit" selected features from other folders, such as preferred display settings.
Slashdot Mirror
He was talking about Comcast.
It's in their blood. Now they can suck faster.
But one could see the car industry as a likely source of new jobs to replace the horse jobs. We don't have anything equivalent in proportion.
A robot may replace 10 jobs for every 1 bot repair or design job it creates. (And they may soon be able to fix themselves.) Houston, we have a ratio problem. As somebody pointed out, industrial-age improvements magnified human ability, rather than outright replaced humans.
Perhaps we are just not spotting the new replacement jobs equivalent to horse-to-cars, but after bringing up this issue many times, nobody else has spotted it either.
Let's see if 20 years from now we slap ourselves on the forehead and say, "There it is, the Magic Gap! So obvious in hindsight, how could I be so dense! We are all.....belly dancers!"
And cows (head duck)
It's what auto-mechanics do more and more of. Read a trouble code, the screen brings up the part info, punch the order button connected to the local warehouse, a paid driver delivers it, mechanic snaps it in plus a couple of screws.
Even plumbing is becoming like that: the plumber swapped a hot/cold regulator module out for a new module in our house. It was a little tricky to snap in place, though, and that's where skill comes in. (My state regulates the hot/cold regulator design per "anti-scalding", for good or bad.)
Either bots will get better at snapping in the replacement modules, or the designs will be simplified enough for bot-enabled snapping in, at least for industrial machinery or heavily watched industries like cars.
http://www.politico.com/magazi...
I'd like to see clear(er) written guidelines for how say customer data should be cared for. And because their may be valid reasons to deviate from the guidelines, perhaps request that the reason for the deviations be written down by the organization and supplied on request to the FTC.
If you bring suitability into this then we could potentially do a lot of slicing and dicing* of the statistics. JavaScript is not suited to be a systems software language for building GUI engines, for example, but has ended up that way through historical accidents.
* No corporate pun intended
I would call that "culturally insensitive" perhaps, but NOT "racism". The R word is used too often. That joke is not demeaning in any definitive or clear sense. If I had implied that kind of food was dangerous or foul, I could see a real reason to complain.
I don't see associating the USA with hamburgers or cowboys offensive in any way to USA citizens unless negative traits were implied to be associated with them, such as obesity (burger) or excess bravado (cowboy).
I see 3 possible levels of association:
1. Associating situations with an ethnic trait or convention
2. Demeaning of an ethnic trait or convention
3. Demeaning of an ethnic group directly ("the X people are bad").
To be on the safe side, we could say "never do #1", but that's PC overkill. If I were an international diplomat, yes #1 probably should be ruled out. But, it's slashdot; we should be able to have a little bit of fun.
Would adding Chris Christie into that joke increase or decrease the racism score?
I would suspect it has more to do with Android apps. It will be interesting to see if Oracle's legal games change that.
If it were American scientists and some Chinese made hamburger jokes, would it be "racist"? I don't know what the exact algorithm/formula is for determining "racism".
Instead, we outsource Fox News and Rush L. to rewrite it. Those with money/power always find a way to tilt history.
So, does this mean tastier Dim Sum?
You will all be cows in 10 billion years. Practice for it, say MOOOOO!
"as an artist. Make him get a day job, perhaps in dentistry or politics."
There certainly is a lot of shilling going on.
Are there such things?
Then we'd have bloated dates like 12/25/13827642763
Thank You Jesus!
So Americans have to improve their lying skills to compete in the world.
This. Is. Slashdot!
Arguing with the boss over that is usually a no-no. If he/she is a jerk, it's best to update your resume and move on.
They seem implemented with arbitrary and inconsistent limits or usage steps per OS or file-system version. This typically makes any product that uses them married to a platform. It will probably require a "blockbuster" product to make anyone care enough to clean them up.
I press "6" with my middle finger, three times.
If file systems allowed arbitrary attributes per folder/file, then file systems could serve as both CMS's and light-duty CRUD storage. Most intranet CMS content is just lists of documents and links, with a few notes. They could be queried via SQL or an SQL-like language[1], along with the usual file-oriented techniques.
In addition to the arbitrary attributes, a set of common attributes would be reserved, at least by convention:
* title (file/folder name)
* synopsis
* content (file bytes)
* type (type of content, perhaps by extension)
* thumbnail (or icon)
* create-date (date/time)
* modif-date
* orig-author (writer user name)
* modif-author (who changed it)
* sequence (preferred ordering [2])
* hidden (internal or system files/rows)
Conventions for display preferences and perhaps an HTML template(s) per folder or folder groups[3] could also be defined as part of the convention.
And perhaps per-folder[3] settings can enforce certain attributes or constraints, such as making synopsis required, for example.
Think about it: a flexible data tool without totally reinventing the wheel. We just soup-up existing file systems (or at least file conventions). Something is more likely to be accepted if it's similar to familiar tools--file systems and RDBMS in this case.
[1] Comparing operations may have to be more type-explicit if using dynamic or "indicator-free" types.
[2] Ordering by "convention" attributes (above) would typically be available, but sometimes the author wants explicit control of ordering
[3] Folders could perhaps define a path and/or grouping so that they can "inherit" selected features from other folders, such as preferred display settings.