The problem is, since they're using statistical methods, you can become "interesting" without actually being interesting. Which is precisely why people need to be involved at all levels, not merely from some dark lair at the top.
When a weather service runs a simulation, they need a lot of compute nodes that can communicate with very little latency and very high throughput. As far as I know the interconnects in a supercomputer are much more exotic than the networks in your average data center.
The Cloud is based primarily on PC technology. PC technology has its place, but it differs from mainframe technology (designed for robustness and data throughput) and from supercomputer technology (designed for multiple rapid concurrent computations).
To give an example, decades ago, Cray Computers were assembled by people (housewives) who were allowed to spend no more time than they could be maximally effective in, using wires cut to millimeter-precise lengths. Because the speed of light (electricity) through the wires was a critical part of the architecture and too long or short a wire would screw up the signal timing. No "more work hours equals more productivity" there!
Good joke, though. Weather. "cloud" computing. Yuk, yuk, yuk.
Seriously, the Earth doesn't go through weather ups and downs that you could jack in more nodes for. When it's hurricane season in one hemisphere, it isn't in the other and vice versa. Jet streams shift, El niños and their relatives come and go - something's always happening somewhere, and sooner or later it spreads everywhere. The massive early snowstorms of this past week started out as monster tropical storms on the other side of the planet.
I guarantee you, by the time the day is through, 2/3s of the posts here will say something along the lines of "What's the problem with the book? It's just like real life!"
Barbie is based on a doll who is based on a cartoon about a prostitute. She's a whore turned housewife. So she's actually an abusive stereotype to a number of groups and subgroups...
That's a terrible thing to say about Barbie.
Before she became a computer engineer, she worked at McDonalds. And drove a brand-new pink corvette. And lived in a Malibu beach house. And I'm sure she was paying her way through the IT program in college. All on her salary from McDonalds.
You say a lot. I say a little. It has the virtue that there are less moving parts that have to function properly for it to work.
There's an old adage: "Nothing succeeds like success". It has variants like "Nobody got fired for buying IBM (Microsoft, or whatever the current 800 lb gorilla in the industry is).
Microsoft and IBM didn't reach monopoly size because some government passed a law favoring them or restricting their competitors. They reached it because the bigger they got the bigger they could get. Most free markets are what engineers call "positive feedback loops". Once you're big enough, you can certainly buy government, but once you're big enough, you can buy just about anything at wholesale rates.
As the tentacles of systemd reach out and penetrate more areas of the system, more applications will inevitably require systemd which means that a Linux installation without systemd will only be able to run a small subset of Linux apps. Even though there are alternatives currently in the works for the init portion of systemd, applications are beginning to depend on the tightly-coupled processes that systemd requires which means that the only viable replacement for the entirety of systemd is another implementation of tightly-coupled procs which defeats the purpose of writing an alternative in the first place.
This isn't how it should have to be.
One of the major faults with init scripts was that when you had inter-dependent systems you had to modify scripts to allow for the mandatory and optional pre-requisite processes and resources. What systemd could have been was an Inversion of Control framework where the initscripts morphed into wireable components so that the system administrator could define whatever network of dependencies he/she required.
Instead, the components are limited in functions compared to init scripts, and the binary logging subsystem was jammed in whether it was needed/wanted or not. Which it wasn't.
Systemd works OK in Fedora, so I don't see a serious need to run to Slackware, but if I was running a server, then I would probably use FreeBSD anyway, not Linux.
Not.
I got reminded why I didn't like this idea yesterday.
System wouldn't reboot. Flipped to the alternate consoles to see the logs and command shell. GONE.
Finally figured it out. It was a USB device and it had to be unplugged or the whole boot process would hang without any information displayed.
I've said it before and I'll say it over and over. I like the concept of a wireable process management system. But what systemd did to logging is an abomination. I didn't like binary logs in OS/2 and I still despise them.
Ever read a credit card agreement, insurance contract, or mortgage agreement?
There's a huge difference between a private contract you willingly enter into, and a government edict that you are forced into and cannot opt out of.
>
You mean like the Microsoft EULA?
When there's no alternative to the private contract - and especially when it's a contract by fiat, defined solely by someone bigger and better-funded than you are, like it or lump it, then the main difference becomes what sort of pressure little ant you can place on big gorilla.
At least with a government, you can vote the bastards out. And someday maybe we even will.
Or maybe you thought you could buy 100 shares of a company and expect to carry equal weight with the guys who hold 10,000 or so.
And as an added benefit, when the trucking companies go out of business, we won't have to fund the roads anymore at all because everyone will die of starvation except for the farmers, and they won't need the roads.
... Until they need fuel for all that farm machinery.
Still unclear. The core account management DDL for MySQL is just about the same syntax as any other SQL-standard database, although you can also muck with the raw security tables if you prefer. Are you looking for an LDAP tie-in? Or maybe just a DDD (drag/drop/drool) GUI management tool?
In general, you'll find that while Oracle and Microsoft offer a lot of stuff under their respective brand labels, FOSS projects usually spins off side projects from third parties. The net effect is about the same except that in proprietary systems, you get exactly what the vendor wishes to offer but they'll tell you what it is, versus the FOSS approach where you typically spend a couple of hours googling (and/or checking the "featured products" page on the main product site), but you often get a choice of tools.
And, of course, the FOSS systems are generally more open to general external tie-ins in order to facilitate the development of tools without wreaking havoc on the core product. Which is why people scream so loudly about the "black box" approach that Linux systemd offers. Or was in "inflicts"?
It looks like the Republicans will have 54 Senators in 2015, in part, I think, to support given them by libertarians (except perhaps in Virginia where a Libertarian candidate took support from the Republican primarily).
Might this be a move by Democrats to reach out to libertarians who tend to be the strongest opponents of the surveillance of the public by government?
I wouldn't count on it.
The elected representatives themselves aren't Libertarian, they're Republican. Doesn't matter if the voters leaned Libertarian or not. The Party isn't interested in Libertarian ideals excepting the ones that they find convenient.
Reallocated_Sector_Count
sectors that the drive successfully replaced
Reported_Uncorrectable_Errors
errors that could not be recovered by ECC
Command_Timeout
controller hanging and had to be resetted
Current_Pending_Sector_Count
sectors to be replace by the next write access
Offline_Uncorrectable
sectors that the drive tried to repair, but failed (try offline test, maybe it is not dead yet)
Did some idiot mod you DOWN?
This is information that bears frequent repetition.
Newer drives will relocate bad sectors to free reserved space they keep for that purpose.
IBM Mainframe drives did that back in the 1960s.
From what I've seen of hard drives, they're a lot like silicon wafers. Rarely perfect, but as long as they're "good enough", the controller maps around the bad spots that they came with as well as a certain number of ones that form over the operating life.
As a security oriented guy the big difference for me is the complete lack of built in security features in pretty much anything that isn't Oracle or MS SQL. MySQL is especially bad in this regard in my experience. Some agency will decide to switch to it because it's free and they expect a lot of savings. Then they discover that lots of the security features that were givens with Oracle or MS SQL just aren't there in MySQL. Sure they can license packages and whatnot to provide for those security options in many cases but then it's not free anymore. They could write their own security packages, but again that will take a lot of time and money to develop, so not actually free. It could definitely end up cheaper in the long run but most program managers I've worked with don't seem to look at that as a viable sell to their customers.
I have no idea what you're talking about. The MySQL server has extremely fine-grained security and it took me a long time to get happy with what it would let me do. Likewise for PostgreSQL. If the rules aren't just right, you can be bounced and nary a log message in sight to give a clue.
Most of the major security issues I've seen in database-related systems had nothing to do with lack of security in the database (of which Oracle often makes headlines), but rather in the apps that are accessing the database. In fact, one of the biggest security holes I routinely encounter outside of blatant SQL Injection comes from "clever" people who don't use the industry standard login and security mechanisms and invent their own.
Clue: I don't care if you ARE the Lord High Architect and Stephen Hawking routinely calls you when he needs help on hard problems. If you are not a full-time security expert with no silly distractions such as actual applications and if you don't have serious security training, DON'T try and invent your own security system. Use one that's already been vetted, proven, debugged and documented. By people who ARE full-time security experts.
There's also a HUGE ecosystem, very profitable, that after two dozen years, actually works-- expensive as it is. Oracle DBAs and SQL coders aren't the sort of person that's after the latest "edgy" new db scheme.
I would venture that most of them don't like JSON, have no clue for hadoop, and are the online/never-fail sorts. They're not going to use REST against an AJAX app, are clueless about puppet, and believe in middleware. Not gonna get them to fix what they perceive as not-broken.
There is a small amount of wisdom in this philosophy, but like COBOL, mainframes/minis, and AS/400s/AIX, time will eventually pass them by, slowly, but unerringly, IMHO.
Well, that's a real shame, because my Oracle XML book's about 10 years old now. Presumably Oracle's done equivalents for JSON, and I'm pretty sure that they've got some AJAX tools in the mix, too.
Not that I follow that stuff very closely. Most of the ReST, AJAX, and JSON stuff I've done is either in the general Oracle Sun Java libraries or from one of the major third-party suppliers such as Apache or CodeHaus.
I'll grant that some people do dig their little hole in the ground and never get any bigger, but that hasn't been a safe way to live for at least 20 years.
One of the reasons why I avoid stored procedures wherever possible is because the convenience is outweighed by the vendor lock-in.
Yes, there are times when you need the kind of performance that only complex server-based functions can provide Or times when no more distant means of access can keep a complex environment properly ACID.
And when that's the case, I'll used stored procedures.
But for run of the mill stuff, no. You end up with half the application in Java/C/.Net, whatever, and half in the database and you constantly have to scramble back and forth to figure out where important things are happening. And if the CEO comes in and decides no more money for Larry, you've dug a real deep hole.
MySQL was late to the party when it came to transactions and stored procedures. It's pretty good these days, but PostgreSQL has more practice at it, and the PostgreSQL query language is more like Oracle's PL/SQL, so the conversion costs are lower.
One of the most common underpinning infrastructures to the NoSQL databases is MySQL.
Oracle and DB2 may have virtues in certain circumstances, but they're a royal bitch to deal with, and in many cases, not worth the money, even in major shops for anything except the very largest applications.
From an administrative point of view, they're a joke. Ever tried to dump a DB2 database out to raw SQL using the IBM-supplied utilities? Ever tried to port a DB2 database from an iSeries machine to a Linux DB2 server? Or even an LUW Windows DB2 database to a an LUW Linux database? DB2 can't even do a decent job of creating a new table from a selection off an old table - at least Oracle can do that much. Boolean data types? Nope. Error messages that can be decoded in under a day? How about this this Oracle classic (translated into the vernacular) "One of the 145 columns in your SELECT statement has an invalid data type. Guess which one, sucker!" DB2 has an almost identical message. Almost as useful as the old mainframe error message that says "EROPT = ABE OR AN INVALID CODE", explanation: "An invalid code or ABE was specified for EROPT", actual meaning: either your COBOL program specified a wrong length record or the tape drive's on fire - usually the first, but only by consulting the system data areas and decoding the status bits would tell you for certain.
It's a LOT cheaper to install, maintain, and even repair MySQL and PostgreSQL than it is to do any of those things from Oracle or DB2, and these days, the cost of the support personnel and their available time figures more highly than the cost of the software. Even if the software wasn't free.
"But Oracle and IBM provide Fortune-level service!" Yeah. Right. "Please stay on the line, approximate waiting time is now 45 minutes. Your call is VERY important to us". Been there. Or maybe a forum where you can be told to cycle the server in Bombay Welsh. In other words, unless you bulk-order mainframes in lots of 6 or more, you'll get better support in most cases from the FOSS stuff, PLUS if all else fails, you can examine and even modify the source code.
Last Oracle shop I worked in was one of the largest financial institutions in the state. I'm not sure ANY of our systems needed anything on the order of an Exabyte server - even the Financials. Most of the stuff would have run just fine on PostgreSQL with hardly any code mods and without the $64K-plus cost of an Oracle server. Then again, they cut the size of the Oracle support team in half when the recession hit, so I guess they didn't figure that Oracle expertise was worth a whole lot.
Slashdot Mirror
Surprise! That activates the Corbomite unit!
The problem is, since they're using statistical methods, you can become "interesting" without actually being interesting. Which is precisely why people need to be involved at all levels, not merely from some dark lair at the top.
When a weather service runs a simulation, they need a lot of compute nodes that can communicate with very little latency and very high throughput. As far as I know the interconnects in a supercomputer are much more exotic than the networks in your average data center.
The Cloud is based primarily on PC technology. PC technology has its place, but it differs from mainframe technology (designed for robustness and data throughput) and from supercomputer technology (designed for multiple rapid concurrent computations).
To give an example, decades ago, Cray Computers were assembled by people (housewives) who were allowed to spend no more time than they could be maximally effective in, using wires cut to millimeter-precise lengths. Because the speed of light (electricity) through the wires was a critical part of the architecture and too long or short a wire would screw up the signal timing. No "more work hours equals more productivity" there!
Good joke, though. Weather. "cloud" computing. Yuk, yuk, yuk.
Seriously, the Earth doesn't go through weather ups and downs that you could jack in more nodes for. When it's hurricane season in one hemisphere, it isn't in the other and vice versa. Jet streams shift, El niños and their relatives come and go - something's always happening somewhere, and sooner or later it spreads everywhere. The massive early snowstorms of this past week started out as monster tropical storms on the other side of the planet.
Advanced maths is hard
You know, Barbie said the same thing!
Where do you find actual chemistry sets with actual chemicals in them that can actually make interesting things?
At junk/antique stores. Those made in the 1960s and earlier, generally haven't been crippled for safety.
In the 21st Century Land of the Free and Home of the Brave, only terrorists study chemistry. So they can make bombs to destroy our Freedoms.
Besides, the liability lawyers wouldn't let us have them even if the Feds would.
I guarantee you, by the time the day is through, 2/3s of the posts here will say something along the lines of "What's the problem with the book? It's just like real life!"
Well, if you replaced Barbie with Zuckerberg...
Barbie is based on a doll who is based on a cartoon about a prostitute. She's a whore turned housewife. So she's actually an abusive stereotype to a number of groups and subgroups...
That's a terrible thing to say about Barbie.
Before she became a computer engineer, she worked at McDonalds. And drove a brand-new pink corvette. And lived in a Malibu beach house. And I'm sure she was paying her way through the IT program in college. All on her salary from McDonalds.
You say a lot. I say a little. It has the virtue that there are less moving parts that have to function properly for it to work.
There's an old adage: "Nothing succeeds like success". It has variants like "Nobody got fired for buying IBM (Microsoft, or whatever the current 800 lb gorilla in the industry is).
Microsoft and IBM didn't reach monopoly size because some government passed a law favoring them or restricting their competitors. They reached it because the bigger they got the bigger they could get. Most free markets are what engineers call "positive feedback loops". Once you're big enough, you can certainly buy government, but once you're big enough, you can buy just about anything at wholesale rates.
No need to peek, if your interest is piqued you can just look, it's pretty public.
Who gave you free reign? You need to tow the line!
As the tentacles of systemd reach out and penetrate more areas of the system, more applications will inevitably require systemd which means that a Linux installation without systemd will only be able to run a small subset of Linux apps. Even though there are alternatives currently in the works for the init portion of systemd, applications are beginning to depend on the tightly-coupled processes that systemd requires which means that the only viable replacement for the entirety of systemd is another implementation of tightly-coupled procs which defeats the purpose of writing an alternative in the first place.
This isn't how it should have to be.
One of the major faults with init scripts was that when you had inter-dependent systems you had to modify scripts to allow for the mandatory and optional pre-requisite processes and resources. What systemd could have been was an Inversion of Control framework where the initscripts morphed into wireable components so that the system administrator could define whatever network of dependencies he/she required.
Instead, the components are limited in functions compared to init scripts, and the binary logging subsystem was jammed in whether it was needed/wanted or not. Which it wasn't.
Systemd works OK in Fedora, so I don't see a serious need to run to Slackware, but if I was running a server, then I would probably use FreeBSD anyway, not Linux.
Not.
I got reminded why I didn't like this idea yesterday.
System wouldn't reboot. Flipped to the alternate consoles to see the logs and command shell. GONE.
Finally figured it out. It was a USB device and it had to be unplugged or the whole boot process would hang without any information displayed.
I've said it before and I'll say it over and over. I like the concept of a wireable process management system. But what systemd did to logging is an abomination. I didn't like binary logs in OS/2 and I still despise them.
Ever read a credit card agreement, insurance contract, or mortgage agreement?
There's a huge difference between a private contract you willingly enter into, and a government edict that you are forced into and cannot opt out of.
>
You mean like the Microsoft EULA?
When there's no alternative to the private contract - and especially when it's a contract by fiat, defined solely by someone bigger and better-funded than you are, like it or lump it, then the main difference becomes what sort of pressure little ant you can place on big gorilla.
At least with a government, you can vote the bastards out. And someday maybe we even will.
Or maybe you thought you could buy 100 shares of a company and expect to carry equal weight with the guys who hold 10,000 or so.
They can convert to using biofuel, and grow their own.
Well, if it's french, er "freedom" fry oil, then the oversized SUVs will be toodling around the cities and the farmers will be sitting high and dry.
And as an added benefit, when the trucking companies go out of business, we won't have to fund the roads anymore at all because everyone will die of starvation except for the farmers, and they won't need the roads.
... Until they need fuel for all that farm machinery.
There is no downside to lower gas prices. lower prices on anything is always a positive.
And you buy all your milk and pet food from China.
Still unclear. The core account management DDL for MySQL is just about the same syntax as any other SQL-standard database, although you can also muck with the raw security tables if you prefer. Are you looking for an LDAP tie-in? Or maybe just a DDD (drag/drop/drool) GUI management tool?
In general, you'll find that while Oracle and Microsoft offer a lot of stuff under their respective brand labels, FOSS projects usually spins off side projects from third parties. The net effect is about the same except that in proprietary systems, you get exactly what the vendor wishes to offer but they'll tell you what it is, versus the FOSS approach where you typically spend a couple of hours googling (and/or checking the "featured products" page on the main product site), but you often get a choice of tools.
And, of course, the FOSS systems are generally more open to general external tie-ins in order to facilitate the development of tools without wreaking havoc on the core product. Which is why people scream so loudly about the "black box" approach that Linux systemd offers. Or was in "inflicts"?
It looks like the Republicans will have 54 Senators in 2015, in part, I think, to support given them by libertarians (except perhaps in Virginia where a Libertarian candidate took support from the Republican primarily).
Might this be a move by Democrats to reach out to libertarians who tend to be the strongest opponents of the surveillance of the public by government?
I wouldn't count on it.
The elected representatives themselves aren't Libertarian, they're Republican. Doesn't matter if the voters leaned Libertarian or not. The Party isn't interested in Libertarian ideals excepting the ones that they find convenient.
I could never imagine why it is even POSSIBLE to disable it. If you don't want to read it, just freakin don't read it.
I think there's some routine testing going on that adds overhead unless you disable it.
Did some idiot mod you DOWN?
This is information that bears frequent repetition.
Newer drives will relocate bad sectors to free reserved space they keep for that purpose.
IBM Mainframe drives did that back in the 1960s.
From what I've seen of hard drives, they're a lot like silicon wafers. Rarely perfect, but as long as they're "good enough", the controller maps around the bad spots that they came with as well as a certain number of ones that form over the operating life.
As a security oriented guy the big difference for me is the complete lack of built in security features in pretty much anything that isn't Oracle or MS SQL. MySQL is especially bad in this regard in my experience. Some agency will decide to switch to it because it's free and they expect a lot of savings. Then they discover that lots of the security features that were givens with Oracle or MS SQL just aren't there in MySQL. Sure they can license packages and whatnot to provide for those security options in many cases but then it's not free anymore. They could write their own security packages, but again that will take a lot of time and money to develop, so not actually free. It could definitely end up cheaper in the long run but most program managers I've worked with don't seem to look at that as a viable sell to their customers.
I have no idea what you're talking about. The MySQL server has extremely fine-grained security and it took me a long time to get happy with what it would let me do. Likewise for PostgreSQL. If the rules aren't just right, you can be bounced and nary a log message in sight to give a clue.
Most of the major security issues I've seen in database-related systems had nothing to do with lack of security in the database (of which Oracle often makes headlines), but rather in the apps that are accessing the database. In fact, one of the biggest security holes I routinely encounter outside of blatant SQL Injection comes from "clever" people who don't use the industry standard login and security mechanisms and invent their own.
Clue: I don't care if you ARE the Lord High Architect and Stephen Hawking routinely calls you when he needs help on hard problems. If you are not a full-time security expert with no silly distractions such as actual applications and if you don't have serious security training, DON'T try and invent your own security system. Use one that's already been vetted, proven, debugged and documented. By people who ARE full-time security experts.
There's also a HUGE ecosystem, very profitable, that after two dozen years, actually works-- expensive as it is. Oracle DBAs and SQL coders aren't the sort of person that's after the latest "edgy" new db scheme.
I would venture that most of them don't like JSON, have no clue for hadoop, and are the online/never-fail sorts. They're not going to use REST against an AJAX app, are clueless about puppet, and believe in middleware. Not gonna get them to fix what they perceive as not-broken.
There is a small amount of wisdom in this philosophy, but like COBOL, mainframes/minis, and AS/400s/AIX, time will eventually pass them by, slowly, but unerringly, IMHO.
Well, that's a real shame, because my Oracle XML book's about 10 years old now. Presumably Oracle's done equivalents for JSON, and I'm pretty sure that they've got some AJAX tools in the mix, too.
Not that I follow that stuff very closely. Most of the ReST, AJAX, and JSON stuff I've done is either in the general Oracle Sun Java libraries or from one of the major third-party suppliers such as Apache or CodeHaus.
I'll grant that some people do dig their little hole in the ground and never get any bigger, but that hasn't been a safe way to live for at least 20 years.
One of the reasons why I avoid stored procedures wherever possible is because the convenience is outweighed by the vendor lock-in.
Yes, there are times when you need the kind of performance that only complex server-based functions can provide Or times when no more distant means of access can keep a complex environment properly ACID.
And when that's the case, I'll used stored procedures.
But for run of the mill stuff, no. You end up with half the application in Java/C/.Net, whatever, and half in the database and you constantly have to scramble back and forth to figure out where important things are happening. And if the CEO comes in and decides no more money for Larry, you've dug a real deep hole.
MySQL was late to the party when it came to transactions and stored procedures. It's pretty good these days, but PostgreSQL has more practice at it, and the PostgreSQL query language is more like Oracle's PL/SQL, so the conversion costs are lower.
One of the most common underpinning infrastructures to the NoSQL databases is MySQL.
Oracle and DB2 may have virtues in certain circumstances, but they're a royal bitch to deal with, and in many cases, not worth the money, even in major shops for anything except the very largest applications.
From an administrative point of view, they're a joke. Ever tried to dump a DB2 database out to raw SQL using the IBM-supplied utilities? Ever tried to port a DB2 database from an iSeries machine to a Linux DB2 server? Or even an LUW Windows DB2 database to a an LUW Linux database? DB2 can't even do a decent job of creating a new table from a selection off an old table - at least Oracle can do that much. Boolean data types? Nope. Error messages that can be decoded in under a day? How about this this Oracle classic (translated into the vernacular) "One of the 145 columns in your SELECT statement has an invalid data type. Guess which one, sucker!" DB2 has an almost identical message. Almost as useful as the old mainframe error message that says "EROPT = ABE OR AN INVALID CODE", explanation: "An invalid code or ABE was specified for EROPT", actual meaning: either your COBOL program specified a wrong length record or the tape drive's on fire - usually the first, but only by consulting the system data areas and decoding the status bits would tell you for certain.
It's a LOT cheaper to install, maintain, and even repair MySQL and PostgreSQL than it is to do any of those things from Oracle or DB2, and these days, the cost of the support personnel and their available time figures more highly than the cost of the software. Even if the software wasn't free.
"But Oracle and IBM provide Fortune-level service!" Yeah. Right. "Please stay on the line, approximate waiting time is now 45 minutes. Your call is VERY important to us". Been there. Or maybe a forum where you can be told to cycle the server in Bombay Welsh. In other words, unless you bulk-order mainframes in lots of 6 or more, you'll get better support in most cases from the FOSS stuff, PLUS if all else fails, you can examine and even modify the source code.
Last Oracle shop I worked in was one of the largest financial institutions in the state. I'm not sure ANY of our systems needed anything on the order of an Exabyte server - even the Financials. Most of the stuff would have run just fine on PostgreSQL with hardly any code mods and without the $64K-plus cost of an Oracle server. Then again, they cut the size of the Oracle support team in half when the recession hit, so I guess they didn't figure that Oracle expertise was worth a whole lot.
Most movies and TV shows take place in a universe where the only sentient beings are humans from Earth.
Quite a few seem to be based in a universe where there aren't any sentient beings at all. We call them "reality TV".