It's where we get our news, share our political views, and interact with politicians.
Really? I have never got my news from Facebook, never! People forget that many of those so called Facebook accounts are accounts held by single entities, and for others, they are kind of dormant.
Broadly speaking, among heavy web users, you're a rarity. Facebook, Twitter, and other social network sites (but those two in particular) are exceedingly popular. Facebook and Google essentially control the advertising market, and in many cases FB has enough aggregate data on its users to predict things about them before they know it (eg, a relationship forming). With that type of data, it's easy to manipulate presentation and Facebook has in fact already admitted to doing it experimentally on unwitting users. (Result: Yes, Facebook, Inc. can manipulate your mood.)
I don't think Facebook's and Zuckerberg situation is anything new, historically speaking.
It seems very similar to me to the power that newspaper conglomerate owners held over the past few centuries in America: William Randolph Hurst, Rupert Murdoch, etc.
Actually, I'd say it's quite different. Ginormous "social network systems" are ubiquitous enough that their singular (rather than collective) power far exceeds any particular media outlet, in part because it's not clear that you're dealing with "press" at all.
Facebook, Twitter, Google^H^H^H^H^H^H Alphabet, etc. tread the line between media facilitators and pure communications methods at this point. Perhaps not quite as "common carrier" as AT&T's land lines, but something in between in terms of monopolistic manner of controlling data exchange. (Consider: Would it have been OK for AT&T to not route long distance calls for candidates it didn't like in the '40s and '50s?)
People seem to complain about net neutrality and T-Mobile providing free video streaming from sites that agree to lower bandwidth transmission speeds, but are actually defending FB's employees' presumed position here?
Facebook isn't an ISP and doesn't need safe harbor protection. What its end-users need are assurances that it's not intentionally psychologically manipulating them without their consent (you know, like it's already done in 2008, 2012, etc.). FB and Google could collude to sway the election without anyone noticing at all. Trump is completely irrelevant here, and anyone who defends FB's employees' actions purely on the grounds that they don't like the candidate clearly haven't read enough dystopian science fiction in their lifetime.
Actually, I think there is an underlying philosophic problem there. Content below appearance, and from that perspective I sort of want to give Adobe more credit for at least picking a name for mindless flash that captures its essence. In contrast, Apple's "Quick" could be considered better as a distraction, a misdirection of interest, so to speak.
What are you talking about? The "Quick" in QuickTime is in parallel to QuickDraw, which dates back to the earliest, original Macintosh Toolbox and had concepts from the Lisa. The "Time" (obviously) is from its focus on time metadata in the.mov format. Data over time is the key concept within the original QuickTime API.
And yes, things have moved on, but the container format was deemed flexible enough to be used virtually unchanged in MPEG4. Show some respect.
As in, in order to get a real AI, it will need to have this fuzzy logic.
Which by the way will end up making our new Robotic overlords require human slaves to do math for them.
Which we will do incorrectly, causing their entire robotic empire to fall in a matter of hours.
Well, I'm pretty sure it was Hofstadter. One of the discussions on AI and computers I read a long time ago posited (quoting someone else) that an AI would quite possibly not be very good at math. Or rather, would only be about as good at basic math as a human with a calculator would be (ie, good, but not perfect, due to residual/external issues).
Do you really propose that thirty modpoints should be needed to offset a handful of mistaken moderators?
Well... One benefit of the Slash moderating system is that moderations are limited to +5 or -1. It's never *too* hard to reverse a bad moderation. And, ideally, meta-moderation helps.
In other systems, something that 1000 people have upvoted is basically impossible to correct. Slash is a bit more democratic and normalized in that way.
I can't speak to Yum, because I'm not intimately familiar with the process. But, Apt packages are only as good as the developers that write them. Having done work to package "upstream" versions of Thrift and Boost, and backporting literally dozens of packages from "New" versions of Ubuntu to work on my company's "older" LTS version of Ubuntu... I can assure you that dependency hell is still alive and kicking.
As a Red Hat / RPM guy, this kind of confirms what I'd suspected from my relatively brief interactions on the Debian side -- it's an ecosystem and tooling problem more than anything. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.
Boost and other "no stable release" libraries are a distinct problem. At that point, you might as well simply be installing static libraries again at compile time. If you need dynamic environments at compile time, that's what you'd use SCL's (Software Collections) for, such as https://www.softwarecollections.org/en/scls/denisarnaud/boost157/
Obviously, taking a newer/older package from a different core release, or a different distribution, is going to give you dependency problems. (It astonishes me that people still think rpmfind.net is expected to "just work" when doing an install onto their box...) If you are trying to install something that requires (at *runtime* a library that's incompatible with the ABI version of the library that's on your machine, and that doesn't have a set of compatibility libraries present, then the fact that it doesn't work is a feature, not a bug, of dependency resolution.
Otherwise, just recompile the RPM for the release of the OS you're running on (usually a dedicated build host, but doesn't have to be) and install from there. The only tweaking that'd need to be done is if the RPM format itself changed (spec file directives) between that version and the box you're on.
As a recent example - Samba doesn't impose particular version dependences to do a configure && make && make install cycle on a standard Precise or Trusty image; However, if you try backporting the "latest" Samba 4.3.3 image from Xenial back to even Trusty, you will rapidly find yourself looking at a complete fucking mess - why? Because package names and virtual packages and version dependencies for the Xenial version of the package are completely arbitrary. I can take the same code and compile it properly on any Precise or Trusty system, but try building the same version as a Deb package, and it's a host of "dependency not found" errors, all the way down.
Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages. In the VAST majority of cases on the Red Hat side over the past 6-7 years, I can take a current version from the latest Fedora (or even rawhide, the rolling dev branch), recompile it on a previous stable release of Fedora, RHEL, or CentOS, and things work OK so long as there hasn't been an incompatible ABI change. The main problems that have cropped up in recent years are basically because of incompatible.spec file demands and the systemd BS.
Somebody claiming that "package management" is a solved problem on Ubuntu and Debian is someone who's never bothered to actually create one of those "just works!" packages. It's a VERY hard problem, and has a million brittle corner cases that will fuck you sideways if you don't know what you're doing. Not to mention that I literally cannot, right now, update a Trusty system to the latest set of packages available, because at some point along the way, the systemtap package picked up a bug in its preinst or postinst script that prevent the package from upgrading properly, which in turn, means that every time I try
Also, dependency hell goes away because these apps use the advantages of static and dynamic libraries. As long as a package is using a core image (like Ubuntu 16.04), then updates to that image are automatically upgraded to all apps.
This is 2016. What Linux distro out there still has a "dependency hell" problem? Yum and Apt-get are a decade old and handle dependency resolution. If your packages are compiled against a "core image" (or actual, bona fide release) and your repo is generated wrong and you're experiencing "dependency hell" then either: a) someone is doing something wrong, or b) you have an actual, bona-fide file conflict that can't be automatically resolved
Or at least... a Slashcode-like commenting, moderation, and meta-moderation system.
For all we complain about it here, and for all the trolling that occurs, the Slashdot moderation system seems to have passed the test of time reasonably enough.
Perhaps it's a little like that infamous definition of Democracy: It's the worst form of government except for all the others that have been tried.
Cosmo: There I was in prison. And one day I helped a couple of nice older gentlemen make some free telephone calls. They turned out to be, let us say, good family men. Martin Bishop: Organized crime? Cosmo: Hah. Don't kid yourself. It's not that organized.
One of the elements of DevOps is to combine the skillets of developers and sysadmins to shorten the deployment timeframe. In places where it works, it works well. Of course, this wouldn't be required if we raised the expectations and pay of sysadmins (like a flat 15-20k bump, or more, afer passing some type of sufficiently hard qualifying exam)
I'm not particularly a certificate hound, but I think the RHCSA and RHCE are good things for exactly this reason.
And where it all began was the concept and eventual widespread adoption of agile development and continuous deployment practices.
There's a difference between recognizing the limits of testing and ensuring you can rapidly respond if something doesn't go as expected and reverting is likely to be less successful than fixing forward.... and being unable to plan because you have no idea what you're doing and don't understand system troubleshooting.
But someone still has to come in and write the required tool set.
Yes, this group is called OpsEng.
The old model of throwing the code over the wall to system administrators who would deploy it stopped working with agile processes and continuous deployment practices.
If you're throwing over the wall, you're doing it wrong. You should be throwing it above or below you in the stack, with each group having a clear demarcation point and expected SLAs to other groups internally, so planning, risk assessment, and performance expectations can be performed appropriately.
Replacing one broken culture with another one doesn't fix anything; and DevOps nowadays usually results in developers trying to code their way around their lack of systems skills more than systems engineers getting to be able to communicate back to devs.
That is the most immediate benefit but I think the real reason is deeper
For the electricity grid to be stable power in needs to match power out. Currently this is achived mostly through supply-side management but that is expensive, it means leaving generation capacity idle most of the time. "use it or lose it" renewables makes the situation worse.
Smart meters give them the technical ability to introduce variable pricing depending on current load. Obviously there is a legal and political side to introducing that too but having the technical capability in place is the first step.
At least the smart meters they are fitting in the UK also have a remote disconnect contactor. This would allow implementation of higher precision blackouts (i.e. a blackout that exempted people who had medical conditions or exempted people who agree to pay more) in the event of an electricity shortage.
Possibly, but power operations in the US are managed mostly state-by-state. In California, we've already been subject to rolling blackouts (infamously in the early 2000's; less-so recently). They've had the ability to exclude certain locations when they shut off a grid, but it's probably something that needs to be hard-coded. In an emergency, they're more likely to want to cut off a larger chunk at once (simpler, more reliable) than attempt to toggle lots of smaller switches independently.
The Internet of Things falls into a few categories: 1) Devices that are to be used against you. Example: The "Smart Meters", which form a 'mesh' network, and can be turned off remotely to 'save power', etc. Water meters have been made doing the same thing, "to save water". Expect them to first be 'voluntary', and then 'mandatory'. Usage patterns will then be flagged, for 'suspicious' behavior.
Smart Meters are far more about saving money for the utility company. Unless you're outsourcing to the post office (which is designed for this), sending people out to read everyone's meter is expensive and time consuming when simple telemetry can provide what's needed. They only send people out when they think there might be a problem.
Maybe you're thinking of NEST-like thermostats and whatnot, but those are different from "Smart Meters" as the phrase is currently used in the US.
2) Devices that function like the extension of the supermarket loyalty card. Example: The "Smart refrigerator" which keeps track of your diet, what's inside, and what your ordering from the supermarket. All helpfully passed onto 3rd party marketeers. You are the product being sold.
Maybe it's different where you live, but where I'm at supermarket loyalty cards are entirely about market research and correlation for the store. They make money selling offers to other companies, but it's dwarfed by the value you're providing internally. That's why they don't reduce your savings AT ALL if you opt-out of third party marketing through them.
Today's society is about understanding your own value. My value allows me to save 30-40% at VONS if I shop intelligently and use savings when they come up. For me (and roommates I might shop for communally), that's a deal I've taken since they were introduced here in the '90s.
3) Devices that monitor you for 3rd parties. Examples: Smart TVs & Consoles. The smart device watches you, while you watch it. I've read that some refuse to work if they are unplugged from the internet (I think one example was LG TV). I've also read that the manufacturers have worked on image recognition, so they can keep track of who comes & goes during which program segments, to help tailor the audience for advertisers.
Yeah, that's creepy. Apple's invocation of an Orwellian future rings a bit hollow when they were the company that most popularized the telescreens sitting in everyone's pockets.
I don't use a smart TV, but do have a PlayStation which has cameras, though I've disabled that functionality. I actually trust Sony more than I do the other manufacturers here as "collecting personal data" is an insignificant part of their PS business model.
Obviously, I'm a Luddite, and have none of these devices. But I also don't believe that my personal life is any business of an uninvited 3rd party, nor do I believe that when I purchase an appliance, it's the right of the manufacturer to maintain control of it.
Good for you. If you've purchased a device and are happy with how it initially functions, one easy thing to do is to remove the network config you may have already used, then open it up and disconnect (and/or cut) the circuits to the wireless antennae. With luck, there's still a USB firmware update option you might be able to use in the future, but either way it won't be communicating back without your knowledge or without someone having near-physical access to it.
This really reminds me of Apple Events back when they were first introduced in the System 7 release... As best it could at the time, the community was attempting (led by Apple) to adopt a common vocabulary for domain specific nouns and verbs, so that all word processors would understand the terms "sentence" and "paragraph" for example. Or "font size".
Ideally, you'd be able to issue something like this below for *any* WP, even if it wasn't fully Recordable yet:
tell application MyWordProcessor
set the font size of the first word of the second sentence of the third paragraph to 12 end
I don't know how you'd prove it, but even if you proved that it doesn't for the current binary, updates are an issue. Apps update all the time. Updates either need to be audited (update frequency makes this hard), or you have to live without updating, which at some point causes the app to not work.
Yes, this is why hipster agile bullshit is often at odds with heavy certification processes, like FIPS-140-2 and other analysis.
The original AC is mostly right though. If you received a degree in Software Engineering from an accredited university then by all means, you're a Software Engineer. However if you're just a hipster code monkey copy-pasting from stack exchange then you have no business calling yourself an "engineer".
Same thing as garbagemen calling themselves "sanitation engineers".
For once, I'll agree here. A Systems Engineer is not a "programmer" either, and juxtaposing with hipster code monkies is used to distinguish there as well, except in the latter case it's chef recipes, #devops, and declarative config files because shell scripts and the unix command line scare them.
Damage, theft, vandalism, and pranks occurred in the White House complex during the 2001 presidential transition. Incidents such as the removal of keys from computer keyboards; the theft of various items; the leaving of certain voice mail messages, signs, and written messages; and the placing of glue on desk drawers clearly were intentional acts. However, it was unknown whether other observations, such as broken furniture, were the result of intentional acts, when and how they occurred, or who may have been responsible for them.
Why not just allow some other company to also run underground cables in my neighborhood and to my house?
As long as it can provide all the insurance necessary and pass authorizations that it can properly co-exist with everyone else on the poles, in many jurisdictions you can.
Now. Who's going to pay for all that capital you're about to spend several dozens to hundreds of millions on, depending your jurisdiction?
This is a streaming service and should it go away, you will no longer be able to watch the movie you "purchased". You are not allowed to re-sell or format-shift the movie, nor make local backup copies.
Well, maybe. If 4K comes under the jurisdiction of UltraViolet, then hopefully the licensing will be pushed up through them. That's as close to a "permanent" cross-entity license as one can get these days. In most cases, you're purchasing a license even when you have a physical copy. That's why you're not allowed to use it to show the movie for profit.
Please tell me why this is worth $30 when I can torrent the same movie and *actually* own it for free?
Because that's illegal.
I'm with you in terms of preferring to own a physical copy so that I can continue to watch it when my internet is down and I don't have to rely on a dozen different entities to still exist when I do, but I thought we were past the point where people thought they had a "right" to a movie on their own terms. If you don't want to agree to the copyright holder's terms for the movie, don't retrieve/store/watch it.
The fact that something is old does not mean it's ipso facto obsolete or that its design principles haven't remained sound. Conversely, the fact that something just got posted on github yesterday and uses the latest node.js and boost libraries doesn't mean it's been well designed. These are very different things.
I've rarely ever taken the BART and don't live in the the Bay any more, let alone the San Francisco proper, but it'd be nice to have an analysis that doesn't conflate the two.
Better Idea: Don't upload shit to the cloud in the first place.
PlainTalk speech recognition worked fine on a Power Mac 5200 20 years ago, but Apple forced dictation to go through the cloud until 10.9. The Newton MessagePad 2000 had decent handwriting recognition (finally) and workable natural language analysis.
All of these things can be performed locally using the crap-ton of processing power and RAM that today's devices have, but "Siri" sends it all to the cloud.
Want location guessing? Store it locally. Download logic updates for the parsing of that data as Apple makes improvements.
Need user data to iterate over? Surely there can't be a shortage of Bay Area interns with a variety of accents that Apple can bring in for voice recognition training.
If Apple cared about user security, it wouldn't have this data going over the wire to begin with. If Apple wanted to stand up to intelligence services, it would be putting physical disconnect cut-off switches in front of all of its device sensors and recorders (and analog I/O) and make the battery removable. If Apple wanted to stand up to domestic law enforcement, well... no one elected Apple as a co-equal branch of government. We have the court system for that.
If you really feel that sysvinit was something that should be kept around, [a] you're in the substantial minority; even OpenRC is mostly written in C (check their GitHub page if you don't believe me), and [b] you're welcome to maintain it -- and you should, because no one else is willing to.
There's less point NOW, but that's due to the land grab that systemd's developers performed, not due to technical evaluation... and certainly not in the Fedora 15 days. Anyone who's ever been in a large, political org with management trying to gain control of systems and services in such a way that no one objects strenuously enough at any given step, but that makes them difficult to remove at the end, should be that pattern. Or anyone who's ever been a boiled frog.
There was some guy on here complaining that people didn't get enough use out of the actual sysv init's abilities (i.e. things provided by inittab). He was absolutely right. inittab does such a bad job of managing services that practically no one used it -- certainly not for anything important. So people rewrote init functionality into their own scripts. And then they duplicated it, for each script. Sometimes better than other times. For thirty years.
And... what exactly was wrong with that? A core/sbin/init that does very little but reap zombies and for all important actions hands things off to userland scripts? This model works fine for many other aspects of many OS's... A core micro kernel that's simple, auditable, secure, and trusted, and user-level code to do everything else?
A typical argument in favor of systemd was that people writing scripts to imperatively handle startup was somehow wrong, without clearly explaining why. I'll admit that Ubuntu's scripts were a little messy, but (ironically, given how it spread), in RedHat-land things were quite nice. If you didn't want to have a startup script, you could use one of several service managers to deal with the startup and tear down (xinetd, for example). If you wanted one, it was extremely simple to write one.
It's distinctly possible that had OpenRC been more mature, it could have had more uptake. What is completely certain is that sysvinit needed a stake put through its heart, and even though they have (moved a great deal of code into C libraries, added dependency resolution, cgroup support, and parallel startup, and generally) cleaned up the codebase quite a bit, I still don't think they have the right balance. You can put a lot of lipstick on a pig (daemontools, or whatever you like), but most of the time, providing half of the features you really need is worse than providing none at all. Even in OpenRC, the init process either does too much (even for a small codebase there's still stuff in there no one uses), or too little (e.g. without process tracking it has no idea if the services it starts are still running).
Mu.
Seriously, you're begging the question here. If I want a service manager, I should use one. If I want something to hold sockets open for me, I should use a supervisor (inet, xinetd, etc). These all functioned (and function!) perfectly well as independent subsystems. There's very little that MUST be handled in pid1, and very little reason why some-random-administrative-task MUST be handled by something from the systemd-* project vs what was already out there.
What it sounds like you're saying is that you like the way things are broken right now, as opposed to the different broken that some other system provides. That's great for you, but I wouldn't lump anyone else into that box. Especially if you're pining for ye olde init scripts; those aren't
The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.
I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.
CentOS for your development and cloud systems, RHEL for your "important" systems or where it scales directly with revenue generation.
A $300/box license fee per year for commercial support is trivial for large enterprise systems, where the server might be handling $50,000 of annually recurring revenue and probably cost over $10K to begin with.
CentOS and RHEL are functionally identically in everything not involving 'yum' and rhn deployment, and if you're doing anything at the scale of a couple of hundred servers or more the expertise in your SA/SysEng department should be completely transferable.
those lag behind redhat of course, CentOS a month for last release, SL two months
which isn't too bad compared to past
Speaking of the past, it hasn't been like that in forever. CentOS is usually same-day, sometimes a day or two later. The only exception is usually full-point releases, which might be a week or so if something drastic changed in the ISO building/installing process.
RHEL6 > CentOS 6 was a one-off issue, although it did prove that having two downstream distros (one varying, one trying to be a completely binary compatible rebuild) is a good thing.
RHEL will suddenly break your shit mid-release. They won't ship an out-of-tree kernel module or a patch to a kernel driver to save your life, so good luck with RHEL 6 and Intel e1000e NICs (get the -lt kernel from ElRepo; but you can't remove RH Kernel or you break LSB, so have fun managing your bootloader as it keeps switching back to the broken one and then dropping network entirely on a kernel OOPS). They freeze the distro at a point release (6.7, 6.8, 6.9...) as they publish security patches, while ripping out some configuration subsystems and throwing in new ones (what has worked last week no longer works today, and you can freeze your release and not get further support!).
I never use RHEL-style distributions if I can avoid it.
Yeah, this doesn't match my experience at all either. Larger than "normal" changes do happen at the X.n, X.n+1, etc points, of course, but I've hardly ever had *anything* break that wasn't well documented in the notes and usually forced by some sort of outside issue. (Breaks if we change it, breaks if we don't change it.)
About the only thing that really comes to mind was the cluster manager software somewhere between 6.2 and 6.4. Virtually everything else I can think of back to the 4.1/4.2 days has been just the addition of features, moving things from Tech Preview to fully supported, or adding hardware support.
Frankly, I wish the RH/RPM side of the market was structured more like the Debian/dpkg side, where Debian sets long-term stability base and Ubuntu builds on it. If Fedora were built from RHEL/CentOS, it might not have made so many dumb choices over the past 6 years.
Slashdot Mirror
It's where we get our news, share our political views, and interact with politicians.
Really? I have never got my news from Facebook, never! People forget that many of those so called Facebook accounts are accounts held by single entities, and for others, they are kind of dormant.
Broadly speaking, among heavy web users, you're a rarity. Facebook, Twitter, and other social network sites (but those two in particular) are exceedingly popular. Facebook and Google essentially control the advertising market, and in many cases FB has enough aggregate data on its users to predict things about them before they know it (eg, a relationship forming). With that type of data, it's easy to manipulate presentation and Facebook has in fact already admitted to doing it experimentally on unwitting users. (Result: Yes, Facebook, Inc. can manipulate your mood.)
I don't think Facebook's and Zuckerberg situation is anything new, historically speaking.
It seems very similar to me to the power that newspaper conglomerate owners held over the past few centuries in America: William Randolph Hurst, Rupert Murdoch, etc.
Actually, I'd say it's quite different. Ginormous "social network systems" are ubiquitous enough that their singular (rather than collective) power far exceeds any particular media outlet, in part because it's not clear that you're dealing with "press" at all.
Facebook, Twitter, Google^H^H^H^H^H^H Alphabet, etc. tread the line between media facilitators and pure communications methods at this point. Perhaps not quite as "common carrier" as AT&T's land lines, but something in between in terms of monopolistic manner of controlling data exchange. (Consider: Would it have been OK for AT&T to not route long distance calls for candidates it didn't like in the '40s and '50s?)
People seem to complain about net neutrality and T-Mobile providing free video streaming from sites that agree to lower bandwidth transmission speeds, but are actually defending FB's employees' presumed position here?
Facebook isn't an ISP and doesn't need safe harbor protection. What its end-users need are assurances that it's not intentionally psychologically manipulating them without their consent (you know, like it's already done in 2008, 2012, etc.). FB and Google could collude to sway the election without anyone noticing at all. Trump is completely irrelevant here, and anyone who defends FB's employees' actions purely on the grounds that they don't like the candidate clearly haven't read enough dystopian science fiction in their lifetime.
What's next, Flash?
Actually, I think there is an underlying philosophic problem there. Content below appearance, and from that perspective I sort of want to give Adobe more credit for at least picking a name for mindless flash that captures its essence. In contrast, Apple's "Quick" could be considered better as a distraction, a misdirection of interest, so to speak.
What are you talking about? The "Quick" in QuickTime is in parallel to QuickDraw, which dates back to the earliest, original Macintosh Toolbox and had concepts from the Lisa. The "Time" (obviously) is from its focus on time metadata in the .mov format. Data over time is the key concept within the original QuickTime API.
And yes, things have moved on, but the container format was deemed flexible enough to be used virtually unchanged in MPEG4. Show some respect.
As in, in order to get a real AI, it will need to have this fuzzy logic.
Which by the way will end up making our new Robotic overlords require human slaves to do math for them.
Which we will do incorrectly, causing their entire robotic empire to fall in a matter of hours.
Well, I'm pretty sure it was Hofstadter. One of the discussions on AI and computers I read a long time ago posited (quoting someone else) that an AI would quite possibly not be very good at math. Or rather, would only be about as good at basic math as a human with a calculator would be (ie, good, but not perfect, due to residual/external issues).
Intelligence operates at a different level.
Do you really propose that thirty modpoints should be needed to offset a handful of mistaken moderators?
Well... One benefit of the Slash moderating system is that moderations are limited to +5 or -1. It's never *too* hard to reverse a bad moderation. And, ideally, meta-moderation helps.
In other systems, something that 1000 people have upvoted is basically impossible to correct. Slash is a bit more democratic and normalized in that way.
I can't speak to Yum, because I'm not intimately familiar with the process. But, Apt packages are only as good as the developers that write them. Having done work to package "upstream" versions of Thrift and Boost, and backporting literally dozens of packages from "New" versions of Ubuntu to work on my company's "older" LTS version of Ubuntu... I can assure you that dependency hell is still alive and kicking.
As a Red Hat / RPM guy, this kind of confirms what I'd suspected from my relatively brief interactions on the Debian side -- it's an ecosystem and tooling problem more than anything. RPM dependencies are calculated from files and SONAMEs, but can also be specified manually by the packager, including version inequalities of other packages.
Boost and other "no stable release" libraries are a distinct problem. At that point, you might as well simply be installing static libraries again at compile time. If you need dynamic environments at compile time, that's what you'd use SCL's (Software Collections) for, such as https://www.softwarecollections.org/en/scls/denisarnaud/boost157/
Obviously, taking a newer/older package from a different core release, or a different distribution, is going to give you dependency problems. (It astonishes me that people still think rpmfind.net is expected to "just work" when doing an install onto their box...) If you are trying to install something that requires (at *runtime* a library that's incompatible with the ABI version of the library that's on your machine, and that doesn't have a set of compatibility libraries present, then the fact that it doesn't work is a feature, not a bug, of dependency resolution.
Otherwise, just recompile the RPM for the release of the OS you're running on (usually a dedicated build host, but doesn't have to be) and install from there. The only tweaking that'd need to be done is if the RPM format itself changed (spec file directives) between that version and the box you're on.
As a recent example - Samba doesn't impose particular version dependences to do a configure && make && make install cycle on a standard Precise or Trusty image; However, if you try backporting the "latest" Samba 4.3.3 image from Xenial back to even Trusty, you will rapidly find yourself looking at a complete fucking mess - why? Because package names and virtual packages and version dependencies for the Xenial version of the package are completely arbitrary. I can take the same code and compile it properly on any Precise or Trusty system, but try building the same version as a Deb package, and it's a host of "dependency not found" errors, all the way down.
Well, then that's really a problem with the community not enforcing proper requirement standards that reflect reality on important packages. In the VAST majority of cases on the Red Hat side over the past 6-7 years, I can take a current version from the latest Fedora (or even rawhide, the rolling dev branch), recompile it on a previous stable release of Fedora, RHEL, or CentOS, and things work OK so long as there hasn't been an incompatible ABI change. The main problems that have cropped up in recent years are basically because of incompatible .spec file demands and the systemd BS.
Somebody claiming that "package management" is a solved problem on Ubuntu and Debian is someone who's never bothered to actually create one of those "just works!" packages. It's a VERY hard problem, and has a million brittle corner cases that will fuck you sideways if you don't know what you're doing. Not to mention that I literally cannot, right now, update a Trusty system to the latest set of packages available, because at some point along the way, the systemtap package picked up a bug in its preinst or postinst script that prevent the package from upgrading properly, which in turn, means that every time I try
Also, dependency hell goes away because these apps use the advantages of static and dynamic libraries. As long as a package is using a core image (like Ubuntu 16.04), then updates to that image are automatically upgraded to all apps.
This is 2016. What Linux distro out there still has a "dependency hell" problem? Yum and Apt-get are a decade old and handle dependency resolution. If your packages are compiled against a "core image" (or actual, bona fide release) and your repo is generated wrong and you're experiencing "dependency hell" then either:
a) someone is doing something wrong, or
b) you have an actual, bona-fide file conflict that can't be automatically resolved
Or at least... a Slashcode-like commenting, moderation, and meta-moderation system.
For all we complain about it here, and for all the trolling that occurs, the Slashdot moderation system seems to have passed the test of time reasonably enough.
Perhaps it's a little like that infamous definition of Democracy: It's the worst form of government except for all the others that have been tried.
Cosmo: There I was in prison. And one day I helped a couple of nice older gentlemen make some free telephone calls. They turned out to be, let us say, good family men.
Martin Bishop: Organized crime?
Cosmo: Hah. Don't kid yourself. It's not that organized.
One of the elements of DevOps is to combine the skillets of developers and sysadmins to shorten the deployment timeframe. In places where it works, it works well. Of course, this wouldn't be required if we raised the expectations and pay of sysadmins (like a flat 15-20k bump, or more, afer passing some type of sufficiently hard qualifying exam)
I'm not particularly a certificate hound, but I think the RHCSA and RHCE are good things for exactly this reason.
And where it all began was the concept and eventual widespread adoption of agile development and continuous deployment practices.
There's a difference between recognizing the limits of testing and ensuring you can rapidly respond if something doesn't go as expected and reverting is likely to be less successful than fixing forward.... and being unable to plan because you have no idea what you're doing and don't understand system troubleshooting.
But someone still has to come in and write the required tool set.
Yes, this group is called OpsEng.
The old model of throwing the code over the wall to system administrators who would deploy it stopped working with agile processes and continuous deployment practices.
If you're throwing over the wall, you're doing it wrong. You should be throwing it above or below you in the stack, with each group having a clear demarcation point and expected SLAs to other groups internally, so planning, risk assessment, and performance expectations can be performed appropriately.
Replacing one broken culture with another one doesn't fix anything; and DevOps nowadays usually results in developers trying to code their way around their lack of systems skills more than systems engineers getting to be able to communicate back to devs.
That is the most immediate benefit but I think the real reason is deeper
For the electricity grid to be stable power in needs to match power out. Currently this is achived mostly through supply-side management but that is expensive, it means leaving generation capacity idle most of the time. "use it or lose it" renewables makes the situation worse.
Smart meters give them the technical ability to introduce variable pricing depending on current load. Obviously there is a legal and political side to introducing that too but having the technical capability in place is the first step.
At least the smart meters they are fitting in the UK also have a remote disconnect contactor. This would allow implementation of higher precision blackouts (i.e. a blackout that exempted people who had medical conditions or exempted people who agree to pay more) in the event of an electricity shortage.
Possibly, but power operations in the US are managed mostly state-by-state. In California, we've already been subject to rolling blackouts (infamously in the early 2000's; less-so recently). They've had the ability to exclude certain locations when they shut off a grid, but it's probably something that needs to be hard-coded. In an emergency, they're more likely to want to cut off a larger chunk at once (simpler, more reliable) than attempt to toggle lots of smaller switches independently.
The Internet of Things falls into a few categories:
1) Devices that are to be used against you.
Example: The "Smart Meters", which form a 'mesh' network, and can be turned off remotely to 'save power', etc. Water meters have been made doing the same thing, "to save water". Expect them to first be 'voluntary', and then 'mandatory'. Usage patterns will then be flagged, for 'suspicious' behavior.
Smart Meters are far more about saving money for the utility company. Unless you're outsourcing to the post office (which is designed for this), sending people out to read everyone's meter is expensive and time consuming when simple telemetry can provide what's needed. They only send people out when they think there might be a problem.
Maybe you're thinking of NEST-like thermostats and whatnot, but those are different from "Smart Meters" as the phrase is currently used in the US.
2) Devices that function like the extension of the supermarket loyalty card.
Example: The "Smart refrigerator" which keeps track of your diet, what's inside, and what your ordering from the supermarket. All helpfully passed onto 3rd party marketeers. You are the product being sold.
Maybe it's different where you live, but where I'm at supermarket loyalty cards are entirely about market research and correlation for the store. They make money selling offers to other companies, but it's dwarfed by the value you're providing internally. That's why they don't reduce your savings AT ALL if you opt-out of third party marketing through them.
Today's society is about understanding your own value. My value allows me to save 30-40% at VONS if I shop intelligently and use savings when they come up. For me (and roommates I might shop for communally), that's a deal I've taken since they were introduced here in the '90s.
3) Devices that monitor you for 3rd parties.
Examples: Smart TVs & Consoles. The smart device watches you, while you watch it. I've read that some refuse to work if they are unplugged from the internet (I think one example was LG TV). I've also read that the manufacturers have worked on image recognition, so they can keep track of who comes & goes during which program segments, to help tailor the audience for advertisers.
Yeah, that's creepy. Apple's invocation of an Orwellian future rings a bit hollow when they were the company that most popularized the telescreens sitting in everyone's pockets.
I don't use a smart TV, but do have a PlayStation which has cameras, though I've disabled that functionality. I actually trust Sony more than I do the other manufacturers here as "collecting personal data" is an insignificant part of their PS business model.
Obviously, I'm a Luddite, and have none of these devices. But I also don't believe that my personal life is any business of an uninvited 3rd party, nor do I believe that when I purchase an appliance, it's the right of the manufacturer to maintain control of it.
Good for you. If you've purchased a device and are happy with how it initially functions, one easy thing to do is to remove the network config you may have already used, then open it up and disconnect (and/or cut) the circuits to the wireless antennae. With luck, there's still a USB firmware update option you might be able to use in the future, but either way it won't be communicating back without your knowledge or without someone having near-physical access to it.
This really reminds me of Apple Events back when they were first introduced in the System 7 release... As best it could at the time, the community was attempting (led by Apple) to adopt a common vocabulary for domain specific nouns and verbs, so that all word processors would understand the terms "sentence" and "paragraph" for example. Or "font size".
Ideally, you'd be able to issue something like this below for *any* WP, even if it wasn't fully Recordable yet:
tell application MyWordProcessor
set the font size of the first word of the second sentence of the third paragraph to 12
end
I don't know how you'd prove it, but even if you proved that it doesn't for the current binary, updates are an issue. Apps update all the time. Updates either need to be audited (update frequency makes this hard), or you have to live without updating, which at some point causes the app to not work.
Yes, this is why hipster agile bullshit is often at odds with heavy certification processes, like FIPS-140-2 and other analysis.
The original AC is mostly right though. If you received a degree in Software Engineering from an accredited university then by all means, you're a Software Engineer. However if you're just a hipster code monkey copy-pasting from stack exchange then you have no business calling yourself an "engineer".
Same thing as garbagemen calling themselves "sanitation engineers".
For once, I'll agree here. A Systems Engineer is not a "programmer" either, and juxtaposing with hipster code monkies is used to distinguish there as well, except in the latter case it's chef recipes, #devops, and declarative config files because shell scripts and the unix command line scare them.
Yeah, that turned out to be a myth. I'm sure some pranks happened, but relatively little, compared to the normal and routine wear and tear in offices.
Well, except not: http://www.gao.gov/new.items/d02360.pdf
Why not just allow some other company to also run underground cables in my neighborhood and to my house?
As long as it can provide all the insurance necessary and pass authorizations that it can properly co-exist with everyone else on the poles, in many jurisdictions you can.
Now. Who's going to pay for all that capital you're about to spend several dozens to hundreds of millions on, depending your jurisdiction?
You're not buying the movie, you're licensing it.
This is a streaming service and should it go away, you will no longer be able to watch the movie you "purchased". You are not allowed to re-sell or format-shift the movie, nor make local backup copies.
Well, maybe. If 4K comes under the jurisdiction of UltraViolet, then hopefully the licensing will be pushed up through them. That's as close to a "permanent" cross-entity license as one can get these days. In most cases, you're purchasing a license even when you have a physical copy. That's why you're not allowed to use it to show the movie for profit.
Please tell me why this is worth $30 when I can torrent the same movie and *actually* own it for free?
Because that's illegal.
I'm with you in terms of preferring to own a physical copy so that I can continue to watch it when my internet is down and I don't have to rely on a dozen different entities to still exist when I do, but I thought we were past the point where people thought they had a "right" to a movie on their own terms. If you don't want to agree to the copyright holder's terms for the movie, don't retrieve/store/watch it.
The fact that something is old does not mean it's ipso facto obsolete or that its design principles haven't remained sound. Conversely, the fact that something just got posted on github yesterday and uses the latest node.js and boost libraries doesn't mean it's been well designed. These are very different things.
I've rarely ever taken the BART and don't live in the the Bay any more, let alone the San Francisco proper, but it'd be nice to have an analysis that doesn't conflate the two.
Better Idea: Don't upload shit to the cloud in the first place.
PlainTalk speech recognition worked fine on a Power Mac 5200 20 years ago, but Apple forced dictation to go through the cloud until 10.9. The Newton MessagePad 2000 had decent handwriting recognition (finally) and workable natural language analysis.
All of these things can be performed locally using the crap-ton of processing power and RAM that today's devices have, but "Siri" sends it all to the cloud.
Want location guessing? Store it locally. Download logic updates for the parsing of that data as Apple makes improvements.
Need user data to iterate over? Surely there can't be a shortage of Bay Area interns with a variety of accents that Apple can bring in for voice recognition training.
If Apple cared about user security, it wouldn't have this data going over the wire to begin with.
If Apple wanted to stand up to intelligence services, it would be putting physical disconnect cut-off switches in front of all of its device sensors and recorders (and analog I/O) and make the battery removable.
If Apple wanted to stand up to domestic law enforcement, well... no one elected Apple as a co-equal branch of government. We have the court system for that.
If you really feel that sysvinit was something that should be kept around, [a] you're in the substantial minority; even OpenRC is mostly written in C (check their GitHub page if you don't believe me), and [b] you're welcome to maintain it -- and you should, because no one else is willing to.
There's less point NOW, but that's due to the land grab that systemd's developers performed, not due to technical evaluation... and certainly not in the Fedora 15 days. Anyone who's ever been in a large, political org with management trying to gain control of systems and services in such a way that no one objects strenuously enough at any given step, but that makes them difficult to remove at the end, should be that pattern. Or anyone who's ever been a boiled frog.
There was some guy on here complaining that people didn't get enough use out of the actual sysv init's abilities (i.e. things provided by inittab). He was absolutely right. inittab does such a bad job of managing services that practically no one used it -- certainly not for anything important. So people rewrote init functionality into their own scripts. And then they duplicated it, for each script. Sometimes better than other times. For thirty years.
And... what exactly was wrong with that? A core /sbin/init that does very little but reap zombies and for all important actions hands things off to userland scripts? This model works fine for many other aspects of many OS's... A core micro kernel that's simple, auditable, secure, and trusted, and user-level code to do everything else?
A typical argument in favor of systemd was that people writing scripts to imperatively handle startup was somehow wrong, without clearly explaining why. I'll admit that Ubuntu's scripts were a little messy, but (ironically, given how it spread), in RedHat-land things were quite nice. If you didn't want to have a startup script, you could use one of several service managers to deal with the startup and tear down (xinetd, for example). If you wanted one, it was extremely simple to write one.
1) Cut and paste https://fedoraproject.org/wiki/EPEL:SysVInitScript#Initscript_template
2) Replace 2 or 3 variables
3) Customize further as or if needed.
Done. That's not hard.
It's distinctly possible that had OpenRC been more mature, it could have had more uptake. What is completely certain is that sysvinit needed a stake put through its heart, and even though they have (moved a great deal of code into C libraries, added dependency resolution, cgroup support, and parallel startup, and generally) cleaned up the codebase quite a bit, I still don't think they have the right balance. You can put a lot of lipstick on a pig (daemontools, or whatever you like), but most of the time, providing half of the features you really need is worse than providing none at all. Even in OpenRC, the init process either does too much (even for a small codebase there's still stuff in there no one uses), or too little (e.g. without process tracking it has no idea if the services it starts are still running).
Mu.
Seriously, you're begging the question here. If I want a service manager, I should use one. If I want something to hold sockets open for me, I should use a supervisor (inet, xinetd, etc). These all functioned (and function!) perfectly well as independent subsystems. There's very little that MUST be handled in pid1, and very little reason why some-random-administrative-task MUST be handled by something from the systemd-* project vs what was already out there.
What it sounds like you're saying is that you like the way things are broken right now, as opposed to the different broken that some other system provides. That's great for you, but I wouldn't lump anyone else into that box. Especially if you're pining for ye olde init scripts; those aren't
The issue being that if you break it, you have no one to reasonably point the finger at. This is a big deal in most commercial settings.
I have seen first hand a user of open source software sing the praises, but ultimately couldn't find another company to support *precisely* what they were using, and had to scrap it and frankly have a much worse experience for lack of commercial support. It's a big deal. Whether it should be or not.
CentOS for your development and cloud systems, RHEL for your "important" systems or where it scales directly with revenue generation.
A $300/box license fee per year for commercial support is trivial for large enterprise systems, where the server might be handling $50,000 of annually recurring revenue and probably cost over $10K to begin with.
CentOS and RHEL are functionally identically in everything not involving 'yum' and rhn deployment, and if you're doing anything at the scale of a couple of hundred servers or more the expertise in your SA/SysEng department should be completely transferable.
those lag behind redhat of course, CentOS a month for last release, SL two months
which isn't too bad compared to past
Speaking of the past, it hasn't been like that in forever. CentOS is usually same-day, sometimes a day or two later. The only exception is usually full-point releases, which might be a week or so if something drastic changed in the ISO building/installing process.
RHEL6 > CentOS 6 was a one-off issue, although it did prove that having two downstream distros (one varying, one trying to be a completely binary compatible rebuild) is a good thing.
RHEL will suddenly break your shit mid-release. They won't ship an out-of-tree kernel module or a patch to a kernel driver to save your life, so good luck with RHEL 6 and Intel e1000e NICs (get the -lt kernel from ElRepo; but you can't remove RH Kernel or you break LSB, so have fun managing your bootloader as it keeps switching back to the broken one and then dropping network entirely on a kernel OOPS). They freeze the distro at a point release (6.7, 6.8, 6.9...) as they publish security patches, while ripping out some configuration subsystems and throwing in new ones (what has worked last week no longer works today, and you can freeze your release and not get further support!).
I never use RHEL-style distributions if I can avoid it.
Yeah, this doesn't match my experience at all either. Larger than "normal" changes do happen at the X.n, X.n+1, etc points, of course, but I've hardly ever had *anything* break that wasn't well documented in the notes and usually forced by some sort of outside issue. (Breaks if we change it, breaks if we don't change it.)
About the only thing that really comes to mind was the cluster manager software somewhere between 6.2 and 6.4. Virtually everything else I can think of back to the 4.1/4.2 days has been just the addition of features, moving things from Tech Preview to fully supported, or adding hardware support.
Frankly, I wish the RH/RPM side of the market was structured more like the Debian/dpkg side, where Debian sets long-term stability base and Ubuntu builds on it. If Fedora were built from RHEL/CentOS, it might not have made so many dumb choices over the past 6 years.