Caches don't cache elements which may change frequently. Also, the server frequently modifies elements when they're updated or altered, which breaks caching. Caches mostly work on static elements such as scripts or images and, for example, the client will receive JavaScript constructed such that blocking the script dumps a comment--an image--into the page. That image will be something like a.jpg?1948475898775, looking unique or tied to your session, thus the cache won't have that exact match and will fetch the URI (and get thousands of copies of the zero-pixel image in its cache).
HTTPS can serve from browser cache, and I even used Squid for a while as an HTTPS cache. It can't serve as public cache, however.
All of this is also irrelevant when you log into a Web site (a big part of "cannot be cached" as well).
You can request the content of an IFrame or send an action out of an IFrame to its parent in JavaScript. This allows you to do cross-site request forgery or to inject additional script into a site into which a user has logged. The browser disallows some of these things if the domains don't match; it disallows more of these things if one or both ends are loaded via HTTPS.
The middle-men must have the appropriate secret key known to the endpoint. Both endpoints can see what is written in an encrypted stream. If you can hide something from the client in HTTPS, you can also hide it in HTTP.
In my world routine security updates should not break the system. In fact I should be able to set them to automatic on production and nothing should break.
My experience has been that security updates on RHEL may bring breakage, while on Ubuntu I just leave the automatic updater on.
RHEL "service packs" are bullshit. A RHEL "Service pack" is allowed to be equivalent to an Ubuntu major release: they can upgrade the versions of any software they choose, and often do drop software from the repos, add new software, and upgrade the major version of software. When they do this, they immediately cease supporting the old software. Again: RHEL replaced Apache 2.2 with 2.4 in one point release--an update which slightly changed the syntax of httpd.conf, causing Apache to fail because I needed to enable a module to use IfEnv in 2.4 but didn't in 2.2.
Debian-style releases are as follows: if it worked on the day of release, it will work after any update. No breaking changes.
especially Ubuntu systems I don't solely control as people who prefer this distribution are far more likely to be running things that were installed by a method other than the binary package manager or debs not explicitly made for Ubuntu.
I've always found it hard to get packages in RHEL. I had a mix of CentOS's repos, EPEL, RepoForge, ElRepo, and a few other third-party repos to get Perl modules which were available in Ubuntu Universe. We also had locally-installed Perl and PHP modules through manual building, Pear, or CPAM. This stuff broke frequently, and I tended to fight back against polluting the system with non-repo software (and the mix of repositories occasionally caused breakage itself, but less-so).
It's been pretty rare I couldn't find something in Ubuntu's repositories.
Central management with Ansible or Puppet does give the advantage of making an entire process repeatable and auditable by putting it all in one place. Without these, you're doing untracked changes and manual processes with more potential human error. There aren't really a lot of good options when you get into the weeds, although bringing a proper mower helps, for all the problems that itself brings.
I keep all my internal dev servers on https, as our developers have tended to hard-code HTTP and then complain about cross-domain forwarding restrictions when I redirect to HTTPS in the production server.
I am not rightly able to apprehend what kind of confusion of ideas could provoke such a statement.
HTTP is plain-text, and easy to read in-flight. There are fewer browser restrictions around cross-domain access to HTTP. Tracking HTTP is easy.
HTTPS is encrypted, and has a lot of browser restrictions to prevent cross-domain access. It's harder to make embedded IFrame tracking bugs work with HTTPS.
I often have dealt with the labor union arguments in my parents's house (one side of the family is all union workers, the other side is all raving conservatives) by asking why we don't just pass labor protection laws, as if the government is the biggest union. This has taught me something: the republicans are democrats, and believe in the government doing some seriously leftist shit; they're just attached to the label to the point of mental illness.
Why don't I get a thanks for courageously fighting for humanity and freedom and whatnot?;)
Facebook's continuing development and refinement has been oddly-successful. Myspace fell apart into a crap-heap. The death of Facebook was predicted a half a dozen times for reasons ranging from Diaspora to your parents being on Facebook. I remember when they removed "Random Play" from the profile options (and the ability to search for men/women in your city looking for a relationship of a kind) and people predicted the death of Facebook because they only saw it as a platform for hooking up with college girls. Somehow, it's still here.
Actually, I'm using CrowdPAC instead of something like GoFundMe to comply with FEC rules. There's also ActBlue for similar purpose. These have been vetted by the FEC and ensure that contributors don't exceed FEC limits; they also all carry proper disclaimers.
So yes, I'm fully in compliance with all state and federal election rules. What was your question?
Yes, you got it right. He's not making a consistent argument; he's trying to poison the well.
I support Net Neutrality--its one of the few simple and obvious issues out there--and would introduce a bill charging the FCC with regulating the Internet to ensure equal treatment of access to all services from any given customer, save for configuration to prioritize (not accelerate) time-sensitive traffic (streaming, voice) and de-prioritize (not throttle) non-sensitive bulk traffic.
There are technical details which we can abstract to general details: balanced, equal priority between customers; greater delivery priority for time-sensitive packets. No throttling back a given service or making it so a certain user streaming Hulu is getting bandwidth at the expense of the next house over streaming Netflix.
I support Net Neutrality because the voters in my district are tired of Congressmen who won't push progressive policy policy; we want solutions and actions. It's time for a renewed focus in Congress on well-developed policies using the input of experts instead of political showmanship; and I'm asking you to support me with a modest commitment to my campaign. Even just $10/month helps me reach thousands of additional voters this term.
If you are asserting that what I really meant, that tuning values for disk, filesystem, network stack, process limits, etc can and do in many cases impact stability and performance and that it is not possible to select values that are more cautious defaults at the expense of leaner defaults I do not concede that point.
Well, no, the system won't crash or fail from these things. Also, RHEL has the same out-of-the-box process limits and filesystem tunables as everything else out there--and, for the longest time, raising the max file handles would actually cause a bug to show up in glibc (Drepper spent a decade telling everyone who wanted support for more than 1024 open files in a specific glibc function that they were morons; people worked around it, although it caused Apache to crash now and then). The per-thread stack is also up to the library; musl libc cuts that in half from the defalt--the value used by RHEL, Ubuntu, SuSE, Mint, and everything else using glibc--which caused some bugs to show up in a lean json library, but nobody turns it up in any distribution, and doing so wouldn't really cause a performance issue.
For most tasks I don't have stability issues with either one but updates break things more often on the Ubuntu side and for a typical server running some off the shelf enterprise package rhel is generally closer to what I need. For instance, iptables is without question the best tool for firewall configuration on Linux. Most importantly it is universal. Ubuntu isn't set to save iptables configuration and restore it on reboot out of the box.
Yeah, a few deficiencies there; it's not unstable though. In other news, RHEL is not Windows Server and doesn't come with an Active Directory Domain Controller running out-of-the-box.
RHEL also gives you a reasonable starting config, most of the time you can just add in a couple lines for whatever ports you need to listen on and be done with it.
Debian systems have always come with default working configurations, and they structure them. Apache on RHEL has a giant main httpd.conf, while any Debian derivative splits it out. Some services don't even work on RHEL when you start them up; that happens on Ubuntu, too, for a few services requiring you to hit/etc/default/foo.conf and set ENABLED=true. For the longest time, RHEL also came with tons of open ports, while Debian systems came with no running services.
I don't do any programming on these systems; I do a lot of system administration and a lot of system engineering--taking the software out there and putting it together to accomplish some business goal. If you want to drag your head through lots of stuff paywalled behind Access.Redhat.Com and fragments of mailing list discussions hinting at what the solution might be, go RHEL; if you want things to work out of the box so you can make your way toward a working configuration, go to a Debian derivative. Also you might want to set up Gitlab and track your Ansible configuration in there (and run Ansible from an alpine Docker container so you can keep its config self-contained) if you have a lot of systems to administrate.
Right, and I'm saying we potentially need to expand eavesdropping laws to prevent that kind of data gathering.
Imagine if they put cameras on all the telephone poles, used face recognition software to track you--moving from frame to frame, they can identify which bodies are the same, and have few individuals to compare, thus high accuracy--and thus had a database of everywhere you've gone. They can track your car, your face, your clothing. They have a full log of every movement you've made.
Would that be something you want the government (or anyone) doing?
For instance, buffers, queues, handle counts, etc are more stable when over-sized and more performant when trimmed because the larger these things are the more overhead they carry but the lower the chance of overrun.
Actually, allocating a larger buffer doesn't necessarily incur more performance overhead. On-stack buffers are identical performance cost at any size; however, thread stacks don't grow, so a larger on-stack buffer can lead to crashes depending on usage--something that hit one of the JSON libraries which was allocating 128k buffers. Large malloc() calls at the user level may search through a tree by size, thus not incurring a specific performance overhead or savings compared to small malloc() calls; smaller calls cause more fragmentation in the end, so can be the source of a performance penalty in the long run; and particularly-large malloc() calls just call mmap() for an anonymous mapping. Large mmap() calls have to find contiguous memory, although the kernel operates in such a way as to avoid too much fragmentation.
"Chance of overrun" isn't really a thing. Either you have an overrun error or you don't. Overrun errors are exploitable, and buffer size is generally tuned to not require enlargement. Code is supposed to validate if this is true.
So no, none of these things affect performance or stability in a general sense. In an embedded system, you might; but then you're not working with these general-purpose server OSes.
If you have enough data loss happening in an Enterprise environment to even begin to think you can assess one OS vs another you are definitely doing something wrong
RedHat has pushed things as stable before they were ready--notably GlusterFS, which is not ready for prime time, at all. It's fundamentally-flawed.
There's also been a habit of RHEL of just upgrading things mid-release, calling it a "point release", and overwriting configuration files. Really read your release notes before running updates--although I've had a cluster destroyed by a complete removal of certain configuration utilities from the repositories, replaced with others, which wasn't mentioned in the release notes.
I have no idea what version CentOS/kernel/etc you were running against with this issue but e1000 nics are extremely common and I can't say I've run into any significant issues with them.
It was CentOS 6. It was a known issue. I found the fix on RHEL's own bugzilla, WONTFIX. The particular variant is the e1000e chipset, although it's been noticed that e1000 in the version they were using in early 2016 was broken as all hell. It was common in hardware servers used by a service provider with whom we worked. I think it was the 2.6.32 kernel release they were stuck on for a long time that we were using; I don't remember it being fixed by the time I decommissioned that CDN. It's been a long time since I cared.
The lesson I learned from 4 years of administrating RHEL and 5 of administrating Ubuntu was to never use RHEL (CentOS). It's a broken, bloated, unstable, unpredictable, and outdated piece of shit.
The truth is RedHat claims that the old, old, old, old, ancient versions of software they use, with lots of distributor-maintained patches backported into them--and plenty not--are "stable". They claim stability because, in part, the environment doesn't change: it's the same software for 2 decades. That's as long as they don't decide to upgrade from Apache 2.0 to Apache 2.2 at a point release, with zero days of support between making the release and cutting off official support for anyone running Apache 2.0 on their OS. Basically, if RHEL 7.2 has Apache 2.2 and RHEL 7.3 has Apache 2.4, RHEL 7.2 is unsupported the moment 7.3 comes out; if you call and say Apache is doing funky stuff, they'll tell you to upgrade to the latest Apache 2.4 and call them back.
Compare that to Ubuntu: they won't change software versions in a release, with
So the CCTV images collected by the store or company you are near don't belong to them, they belong to you?
They don't belong to the police, they're not public information, and the police can't walk in and demand videos of you.
You admit that the cops can ask for data. If the company gives them the data just by asking, they don't need a warrant. If they have a warrant, it isn't "asking" anymore.
There have been attempts to force them to turn over data without a warrant. Lots of attempts. The judge pondering the need for a warrant is completely-irrelevant unless the police are allowed to force the release of data without a warrant in one scenario.
You've admitted that a telephone company can release location data about you if they are reporting a crime you've committed against them.
Yep. They have the right to do that, they have standing, and they're reporting a crime. They're volunteering evidence.
If the police order you to allow them to search your house, sans warrant, anything they find is inadmissable in court. Permanently. If you volunteer them a look at your basement marijuana operation, then... well, your fault.
The police should not have the power to compel the release of non-public data without a warrant. We could go a step further and require the police to not ask after it without a warrant unless in conjunction with a reported crime, because the third party has less stake than you. Wiretapping laws actually go further: the police can't tap the phone lines just because Verizon says it's okay; it's your privacy they're invading, by statute, making it a Fourth Amendment violation against you. It's not unreasonable to create new statutes to bring other non-public data under such protection; at the moment, however, they don't have the power to compel the release of that data without a warrant.
That requires a method for identifying the individuals represented by each signal. The IMEI identifies the phone itself; the IMSI identifies the SIM card. The connection is encrypted, although I'm unclear about whether the IMEI is encrypted.
Listening would be akin to eavesdropping, which is also illegal without a warrant in many jurisdictions. This eavesdropping may not be currently illegal; perhaps it should be. I dislike mass data gathering--what is called domestic spying.
It is not public information, but it is also not yours, or my information that we own. It is like getting the video from the liquor store cameras to ID the bastard that just robbed it.
In which case you know there was a robbery and you have reason to believe the video contains the details of the crime.
That's a bit different than walking in and saying, hey, give me all the video on this guy. No reason, just I want it. It's also a bit different from the liquor store reporting a crime and surrendering video related to the details of that crime: they're not under law enforcement order to surrender that information, and are attaching it as relevant to a crime which has been committed against them.
Further, places with CCTV announce they have CCTV. This is to avoid laws forbidding them from recording you without consent of all involved parties.
By contrast, your cell phone provider may or may not be storing data about you long-term, but is presumably recording information for a time—long enough to keep track of where you are at the moment, so the towers function, at a minimum. If you commit a crime against their network, they have every right to bundle relevant data up and submit it with their complaint to the police or courts. Typically, the police initiate the contact, and request they surrender data about you.
There's no reason the government should be allowed to arbitrarily poke into non-public information about you. If they don't have and cannot obtain a warrant, they shouldn't be allowed to thumb through private data at their leisure to build a case about your contact patterns so as to open up an investigation against you. No, they shouldn't be allowed to just request CCTV data, either--your shop can volunteer the relevant recordings when reporting a crime, and they can ask you for the relevant recordings if the next guy over got robbed and they believe you captured something of that, as they'll have a warrant for obtaining that data.
Unacceptable. This is not public information; even voluntary release of your information by the tower operator should be considered a search of your private dealings. We have wire tapping laws because you can just ask the telco to tap a persons line--voluntary release of data by the telco--and that serves as a stand-in for illegally entering your house without a warrant and placing listening devices (search).
Obtaining non-public information from a third party is akin to wire tapping. It's not the same thing; therefor we need stronger privacy laws.
That's actually a handwave statement. Scientifically, how do they know what they've selected is more-stable?
I've had more data loss on CentOS boxes than anything else. There's also an issue with e1000 NICs where the in-kernel driver crashes every couple days if under moderate network load, so you need to build an out-of-tree driver--and RedHat doesn't do out-of-tree drivers because it's "not stable". To get networking to work again, you have to reboot, as the driver won't unload.
What happened to Vonage? You know, the one nobody would touch because you could never tell if Comcast or Verizon would block it on any given month and cut you off from 911 service.
Oh it's enough to matter, for sure--that's why there's a giant minimum-wage debate. We didn't raise the minimum wage for over a decade, so it became smaller (due to inflation). Now we've pinned it to CPI inflation. I want to create a Universal Dividend pinned to productivity using income as a proxy: everyone (adult, planned to eventually be 16+) gets a share of a fixed portion of the income (15%, planned to eventually reach 10%), which grows faster than CPI inflation.
The narrative has always been that real median family income has stagnated, though. You hear about "middle-income stagnation", and you get people saying that the middle-class hasn't seen a real wage income increase since 1979, and other economists saying they've seen 41% growth in wage purchasing power. The fact of the matter is the ones claiming some kind of growth are more-correct than the ones claiming total stagnation.
I have cell phone service with unlimited voice and text, plus 2GB of LTE data and unlimited throttled data per month. It costs $15/month. It's on t-mobile's network. In 1990, even minimum-wage households had landline phones at $30/month here. Most of the minimum-wagers are living... pretty brutally; they have minimal new amenities compared to 20 years ago, yet they do have some. Again: we adjust minimum-wage based on inflation, not based on productivity growth--which is something else my new plan changes.
So, the working-class does see wealth from productivity growth; the rich don't get all the newly-generated income; and the minimum wage is designed to provide nothing in terms of a share of productivity growth--that's not a rich-people-taking-everything trick, but a fact of the government having established it for a purpose of minimum living (Republicans will tell you it's not a living wage; they're wrong) instead of a fair wage.
By the by: be careful reading about "wealth". The wealth of an economy is measured by its productivity; people like to measure wealth by accumulation of assets, then claim the rich have gotten massively-richer because they have things. I like to compare the income flow instead, notably with population considerations, e.g. by looking at CEO cash compensation versus the number of employees (payrolls are paid from revenues; stocks are just inflation of the currency of a company's stock, dumping newly-created shares into the executive's hands while slightly-reducing the number of dollars everyone else holding the stock can get). Oddly enough, highly-paid executives tend to have larger companies with more employees, and receive fewer dollars compensation per employee--just with enormous multipliers. The CEO of Ford, for example, receives about $22.50 per employee per year.
To put this into perspective: an executive making 35x the minimum wage would get $647,500/year; an executive making $1M/year generally has 8,000-10,000 employees. An executive making $647,500/year today would have around 5,000 employees and receive $129.50/year per each, or 6.475 cents per employee per hour. Small business owners with few employees generally make thousands per employee.
Kind of puts a damper on those salary cap arguments, huh? People focus too much on the rich, and not enough on the poor.
I've met plenty; just not in the bottom-of-the-barrel $5/day crew that management wants to hire all the time.
Strike that. I've met one who wasn't the world's best programmer but had repeatedly explained to his colleagues not to architect the way they had, and was absolutely correct about the architecture being crap. That's what got me into project management in the first place: that information was available, it was visible; nobody reacted to it. In the end, we fired the contracted programming team--years later--and put our own team to work un-fucking the finished product. One of those guys still has a good relationship with us.
Slashdot Mirror
If you control the cache, you can use it to cache https.
Caches don't cache elements which may change frequently. Also, the server frequently modifies elements when they're updated or altered, which breaks caching. Caches mostly work on static elements such as scripts or images and, for example, the client will receive JavaScript constructed such that blocking the script dumps a comment--an image--into the page. That image will be something like a.jpg?1948475898775, looking unique or tied to your session, thus the cache won't have that exact match and will fetch the URI (and get thousands of copies of the zero-pixel image in its cache).
HTTPS can serve from browser cache, and I even used Squid for a while as an HTTPS cache. It can't serve as public cache, however.
All of this is also irrelevant when you log into a Web site (a big part of "cannot be cached" as well).
You can request the content of an IFrame or send an action out of an IFrame to its parent in JavaScript. This allows you to do cross-site request forgery or to inject additional script into a site into which a user has logged. The browser disallows some of these things if the domains don't match; it disallows more of these things if one or both ends are loaded via HTTPS.
The middle-men must have the appropriate secret key known to the endpoint. Both endpoints can see what is written in an encrypted stream. If you can hide something from the client in HTTPS, you can also hide it in HTTP.
In my world routine security updates should not break the system. In fact I should be able to set them to automatic on production and nothing should break.
My experience has been that security updates on RHEL may bring breakage, while on Ubuntu I just leave the automatic updater on.
RHEL "service packs" are bullshit. A RHEL "Service pack" is allowed to be equivalent to an Ubuntu major release: they can upgrade the versions of any software they choose, and often do drop software from the repos, add new software, and upgrade the major version of software. When they do this, they immediately cease supporting the old software. Again: RHEL replaced Apache 2.2 with 2.4 in one point release--an update which slightly changed the syntax of httpd.conf, causing Apache to fail because I needed to enable a module to use IfEnv in 2.4 but didn't in 2.2.
Debian-style releases are as follows: if it worked on the day of release, it will work after any update. No breaking changes.
especially Ubuntu systems I don't solely control as people who prefer this distribution are far more likely to be running things that were installed by a method other than the binary package manager or debs not explicitly made for Ubuntu.
I've always found it hard to get packages in RHEL. I had a mix of CentOS's repos, EPEL, RepoForge, ElRepo, and a few other third-party repos to get Perl modules which were available in Ubuntu Universe. We also had locally-installed Perl and PHP modules through manual building, Pear, or CPAM. This stuff broke frequently, and I tended to fight back against polluting the system with non-repo software (and the mix of repositories occasionally caused breakage itself, but less-so).
It's been pretty rare I couldn't find something in Ubuntu's repositories.
Central management with Ansible or Puppet does give the advantage of making an entire process repeatable and auditable by putting it all in one place. Without these, you're doing untracked changes and manual processes with more potential human error. There aren't really a lot of good options when you get into the weeds, although bringing a proper mower helps, for all the problems that itself brings.
I keep all my internal dev servers on https, as our developers have tended to hard-code HTTP and then complain about cross-domain forwarding restrictions when I redirect to HTTPS in the production server.
I am not rightly able to apprehend what kind of confusion of ideas could provoke such a statement.
HTTP is plain-text, and easy to read in-flight. There are fewer browser restrictions around cross-domain access to HTTP. Tracking HTTP is easy.
HTTPS is encrypted, and has a lot of browser restrictions to prevent cross-domain access. It's harder to make embedded IFrame tracking bugs work with HTTPS.
It's so meta, even this acronym.
Slashdot is a social media network.
I often have dealt with the labor union arguments in my parents's house (one side of the family is all union workers, the other side is all raving conservatives) by asking why we don't just pass labor protection laws, as if the government is the biggest union. This has taught me something: the republicans are democrats, and believe in the government doing some seriously leftist shit; they're just attached to the label to the point of mental illness.
Why don't I get a thanks for courageously fighting for humanity and freedom and whatnot? ;)
It's more-correct to think of employees, managers, advertisers, and end users as stakeholders rather than customers.
Facebook's continuing development and refinement has been oddly-successful. Myspace fell apart into a crap-heap. The death of Facebook was predicted a half a dozen times for reasons ranging from Diaspora to your parents being on Facebook. I remember when they removed "Random Play" from the profile options (and the ability to search for men/women in your city looking for a relationship of a kind) and people predicted the death of Facebook because they only saw it as a platform for hooking up with college girls. Somehow, it's still here.
Maybe it means software patents have some purpose, and whatever you're doing isn't innovative.
Invent something non-trivial.
Actually, I'm using CrowdPAC instead of something like GoFundMe to comply with FEC rules. There's also ActBlue for similar purpose. These have been vetted by the FEC and ensure that contributors don't exceed FEC limits; they also all carry proper disclaimers.
So yes, I'm fully in compliance with all state and federal election rules. What was your question?
Yes, you got it right. He's not making a consistent argument; he's trying to poison the well.
I support Net Neutrality--its one of the few simple and obvious issues out there--and would introduce a bill charging the FCC with regulating the Internet to ensure equal treatment of access to all services from any given customer, save for configuration to prioritize (not accelerate) time-sensitive traffic (streaming, voice) and de-prioritize (not throttle) non-sensitive bulk traffic.
There are technical details which we can abstract to general details: balanced, equal priority between customers; greater delivery priority for time-sensitive packets. No throttling back a given service or making it so a certain user streaming Hulu is getting bandwidth at the expense of the next house over streaming Netflix.
I support Net Neutrality because the voters in my district are tired of Congressmen who won't push progressive policy policy; we want solutions and actions. It's time for a renewed focus in Congress on well-developed policies using the input of experts instead of political showmanship; and I'm asking you to support me with a modest commitment to my campaign. Even just $10/month helps me reach thousands of additional voters this term.
If you are asserting that what I really meant, that tuning values for disk, filesystem, network stack, process limits, etc can and do in many cases impact stability and performance and that it is not possible to select values that are more cautious defaults at the expense of leaner defaults I do not concede that point.
Well, no, the system won't crash or fail from these things. Also, RHEL has the same out-of-the-box process limits and filesystem tunables as everything else out there--and, for the longest time, raising the max file handles would actually cause a bug to show up in glibc (Drepper spent a decade telling everyone who wanted support for more than 1024 open files in a specific glibc function that they were morons; people worked around it, although it caused Apache to crash now and then). The per-thread stack is also up to the library; musl libc cuts that in half from the defalt--the value used by RHEL, Ubuntu, SuSE, Mint, and everything else using glibc--which caused some bugs to show up in a lean json library, but nobody turns it up in any distribution, and doing so wouldn't really cause a performance issue.
For most tasks I don't have stability issues with either one but updates break things more often on the Ubuntu side and for a typical server running some off the shelf enterprise package rhel is generally closer to what I need. For instance, iptables is without question the best tool for firewall configuration on Linux. Most importantly it is universal. Ubuntu isn't set to save iptables configuration and restore it on reboot out of the box.
Yeah, a few deficiencies there; it's not unstable though. In other news, RHEL is not Windows Server and doesn't come with an Active Directory Domain Controller running out-of-the-box.
RHEL also gives you a reasonable starting config, most of the time you can just add in a couple lines for whatever ports you need to listen on and be done with it.
Debian systems have always come with default working configurations, and they structure them. Apache on RHEL has a giant main httpd.conf, while any Debian derivative splits it out. Some services don't even work on RHEL when you start them up; that happens on Ubuntu, too, for a few services requiring you to hit /etc/default/foo.conf and set ENABLED=true. For the longest time, RHEL also came with tons of open ports, while Debian systems came with no running services.
I don't do any programming on these systems; I do a lot of system administration and a lot of system engineering--taking the software out there and putting it together to accomplish some business goal. If you want to drag your head through lots of stuff paywalled behind Access.Redhat.Com and fragments of mailing list discussions hinting at what the solution might be, go RHEL; if you want things to work out of the box so you can make your way toward a working configuration, go to a Debian derivative. Also you might want to set up Gitlab and track your Ansible configuration in there (and run Ansible from an alpine Docker container so you can keep its config self-contained) if you have a lot of systems to administrate.
Right, and I'm saying we potentially need to expand eavesdropping laws to prevent that kind of data gathering.
Imagine if they put cameras on all the telephone poles, used face recognition software to track you--moving from frame to frame, they can identify which bodies are the same, and have few individuals to compare, thus high accuracy--and thus had a database of everywhere you've gone. They can track your car, your face, your clothing. They have a full log of every movement you've made.
Would that be something you want the government (or anyone) doing?
For instance, buffers, queues, handle counts, etc are more stable when over-sized and more performant when trimmed because the larger these things are the more overhead they carry but the lower the chance of overrun.
Actually, allocating a larger buffer doesn't necessarily incur more performance overhead. On-stack buffers are identical performance cost at any size; however, thread stacks don't grow, so a larger on-stack buffer can lead to crashes depending on usage--something that hit one of the JSON libraries which was allocating 128k buffers. Large malloc() calls at the user level may search through a tree by size, thus not incurring a specific performance overhead or savings compared to small malloc() calls; smaller calls cause more fragmentation in the end, so can be the source of a performance penalty in the long run; and particularly-large malloc() calls just call mmap() for an anonymous mapping. Large mmap() calls have to find contiguous memory, although the kernel operates in such a way as to avoid too much fragmentation.
"Chance of overrun" isn't really a thing. Either you have an overrun error or you don't. Overrun errors are exploitable, and buffer size is generally tuned to not require enlargement. Code is supposed to validate if this is true.
So no, none of these things affect performance or stability in a general sense. In an embedded system, you might; but then you're not working with these general-purpose server OSes.
If you have enough data loss happening in an Enterprise environment to even begin to think you can assess one OS vs another you are definitely doing something wrong
RedHat has pushed things as stable before they were ready--notably GlusterFS, which is not ready for prime time, at all. It's fundamentally-flawed.
There's also been a habit of RHEL of just upgrading things mid-release, calling it a "point release", and overwriting configuration files. Really read your release notes before running updates--although I've had a cluster destroyed by a complete removal of certain configuration utilities from the repositories, replaced with others, which wasn't mentioned in the release notes.
I have no idea what version CentOS/kernel/etc you were running against with this issue but e1000 nics are extremely common and I can't say I've run into any significant issues with them.
It was CentOS 6. It was a known issue. I found the fix on RHEL's own bugzilla, WONTFIX. The particular variant is the e1000e chipset, although it's been noticed that e1000 in the version they were using in early 2016 was broken as all hell. It was common in hardware servers used by a service provider with whom we worked. I think it was the 2.6.32 kernel release they were stuck on for a long time that we were using; I don't remember it being fixed by the time I decommissioned that CDN. It's been a long time since I cared.
The lesson I learned from 4 years of administrating RHEL and 5 of administrating Ubuntu was to never use RHEL (CentOS). It's a broken, bloated, unstable, unpredictable, and outdated piece of shit.
The truth is RedHat claims that the old, old, old, old, ancient versions of software they use, with lots of distributor-maintained patches backported into them--and plenty not--are "stable". They claim stability because, in part, the environment doesn't change: it's the same software for 2 decades. That's as long as they don't decide to upgrade from Apache 2.0 to Apache 2.2 at a point release, with zero days of support between making the release and cutting off official support for anyone running Apache 2.0 on their OS. Basically, if RHEL 7.2 has Apache 2.2 and RHEL 7.3 has Apache 2.4, RHEL 7.2 is unsupported the moment 7.3 comes out; if you call and say Apache is doing funky stuff, they'll tell you to upgrade to the latest Apache 2.4 and call them back.
Compare that to Ubuntu: they won't change software versions in a release, with
So the CCTV images collected by the store or company you are near don't belong to them, they belong to you?
They don't belong to the police, they're not public information, and the police can't walk in and demand videos of you.
You admit that the cops can ask for data. If the company gives them the data just by asking, they don't need a warrant. If they have a warrant, it isn't "asking" anymore.
There have been attempts to force them to turn over data without a warrant. Lots of attempts. The judge pondering the need for a warrant is completely-irrelevant unless the police are allowed to force the release of data without a warrant in one scenario.
You've admitted that a telephone company can release location data about you if they are reporting a crime you've committed against them.
Yep. They have the right to do that, they have standing, and they're reporting a crime. They're volunteering evidence.
If the police order you to allow them to search your house, sans warrant, anything they find is inadmissable in court. Permanently. If you volunteer them a look at your basement marijuana operation, then... well, your fault.
The police should not have the power to compel the release of non-public data without a warrant. We could go a step further and require the police to not ask after it without a warrant unless in conjunction with a reported crime, because the third party has less stake than you. Wiretapping laws actually go further: the police can't tap the phone lines just because Verizon says it's okay; it's your privacy they're invading, by statute, making it a Fourth Amendment violation against you. It's not unreasonable to create new statutes to bring other non-public data under such protection; at the moment, however, they don't have the power to compel the release of that data without a warrant.
That requires a method for identifying the individuals represented by each signal. The IMEI identifies the phone itself; the IMSI identifies the SIM card. The connection is encrypted, although I'm unclear about whether the IMEI is encrypted.
Listening would be akin to eavesdropping, which is also illegal without a warrant in many jurisdictions. This eavesdropping may not be currently illegal; perhaps it should be. I dislike mass data gathering--what is called domestic spying.
It is not public information, but it is also not yours, or my information that we own. It is like getting the video from the liquor store cameras to ID the bastard that just robbed it.
In which case you know there was a robbery and you have reason to believe the video contains the details of the crime.
That's a bit different than walking in and saying, hey, give me all the video on this guy. No reason, just I want it. It's also a bit different from the liquor store reporting a crime and surrendering video related to the details of that crime: they're not under law enforcement order to surrender that information, and are attaching it as relevant to a crime which has been committed against them.
Further, places with CCTV announce they have CCTV. This is to avoid laws forbidding them from recording you without consent of all involved parties.
By contrast, your cell phone provider may or may not be storing data about you long-term, but is presumably recording information for a time—long enough to keep track of where you are at the moment, so the towers function, at a minimum. If you commit a crime against their network, they have every right to bundle relevant data up and submit it with their complaint to the police or courts. Typically, the police initiate the contact, and request they surrender data about you.
There's no reason the government should be allowed to arbitrarily poke into non-public information about you. If they don't have and cannot obtain a warrant, they shouldn't be allowed to thumb through private data at their leisure to build a case about your contact patterns so as to open up an investigation against you. No, they shouldn't be allowed to just request CCTV data, either--your shop can volunteer the relevant recordings when reporting a crime, and they can ask you for the relevant recordings if the next guy over got robbed and they believe you captured something of that, as they'll have a warrant for obtaining that data.
Unacceptable. This is not public information; even voluntary release of your information by the tower operator should be considered a search of your private dealings. We have wire tapping laws because you can just ask the telco to tap a persons line--voluntary release of data by the telco--and that serves as a stand-in for illegally entering your house without a warrant and placing listening devices (search).
Obtaining non-public information from a third party is akin to wire tapping. It's not the same thing; therefor we need stronger privacy laws.
That's actually a handwave statement. Scientifically, how do they know what they've selected is more-stable?
I've had more data loss on CentOS boxes than anything else. There's also an issue with e1000 NICs where the in-kernel driver crashes every couple days if under moderate network load, so you need to build an out-of-tree driver--and RedHat doesn't do out-of-tree drivers because it's "not stable". To get networking to work again, you have to reboot, as the driver won't unload.
The solution was to switch to Ubuntu.
What happened to Vonage? You know, the one nobody would touch because you could never tell if Comcast or Verizon would block it on any given month and cut you off from 911 service.
Oh it's enough to matter, for sure--that's why there's a giant minimum-wage debate. We didn't raise the minimum wage for over a decade, so it became smaller (due to inflation). Now we've pinned it to CPI inflation. I want to create a Universal Dividend pinned to productivity using income as a proxy: everyone (adult, planned to eventually be 16+) gets a share of a fixed portion of the income (15%, planned to eventually reach 10%), which grows faster than CPI inflation.
The narrative has always been that real median family income has stagnated, though. You hear about "middle-income stagnation", and you get people saying that the middle-class hasn't seen a real wage income increase since 1979, and other economists saying they've seen 41% growth in wage purchasing power. The fact of the matter is the ones claiming some kind of growth are more-correct than the ones claiming total stagnation.
I have cell phone service with unlimited voice and text, plus 2GB of LTE data and unlimited throttled data per month. It costs $15/month. It's on t-mobile's network. In 1990, even minimum-wage households had landline phones at $30/month here. Most of the minimum-wagers are living ... pretty brutally; they have minimal new amenities compared to 20 years ago, yet they do have some. Again: we adjust minimum-wage based on inflation, not based on productivity growth--which is something else my new plan changes.
So, the working-class does see wealth from productivity growth; the rich don't get all the newly-generated income; and the minimum wage is designed to provide nothing in terms of a share of productivity growth--that's not a rich-people-taking-everything trick, but a fact of the government having established it for a purpose of minimum living (Republicans will tell you it's not a living wage; they're wrong) instead of a fair wage.
By the by: be careful reading about "wealth". The wealth of an economy is measured by its productivity; people like to measure wealth by accumulation of assets, then claim the rich have gotten massively-richer because they have things. I like to compare the income flow instead, notably with population considerations, e.g. by looking at CEO cash compensation versus the number of employees (payrolls are paid from revenues; stocks are just inflation of the currency of a company's stock, dumping newly-created shares into the executive's hands while slightly-reducing the number of dollars everyone else holding the stock can get). Oddly enough, highly-paid executives tend to have larger companies with more employees, and receive fewer dollars compensation per employee--just with enormous multipliers. The CEO of Ford, for example, receives about $22.50 per employee per year.
To put this into perspective: an executive making 35x the minimum wage would get $647,500/year; an executive making $1M/year generally has 8,000-10,000 employees. An executive making $647,500/year today would have around 5,000 employees and receive $129.50/year per each, or 6.475 cents per employee per hour. Small business owners with few employees generally make thousands per employee.
Kind of puts a damper on those salary cap arguments, huh? People focus too much on the rich, and not enough on the poor.
I've met plenty; just not in the bottom-of-the-barrel $5/day crew that management wants to hire all the time.
Strike that. I've met one who wasn't the world's best programmer but had repeatedly explained to his colleagues not to architect the way they had, and was absolutely correct about the architecture being crap. That's what got me into project management in the first place: that information was available, it was visible; nobody reacted to it. In the end, we fired the contracted programming team--years later--and put our own team to work un-fucking the finished product. One of those guys still has a good relationship with us.