That's a great comic! If only people checked that the phrase being used were unconnected with them far far better system.
This reminds me of writing. Employers have been complaining about writing for as long as I can remember, at least 30 years. Even in engineering school we were told that we had to learn to write. In high school we did have technical writing, but how much time was spent teaching accurate context free writing college? None, even though professors would tell us that employers were demanding the universities teach writing. Everyone says they want it, but not enough to pay for it. Those with critical thinking skills and writing skills will rise, and those that don't will muddle through and probably go into management.
This story seems like click bait the way it just leaves it as a cliffhanger. so you bombarded an aluminum plate and
Reading the article now (shame on me for not doing so), I suspect there is malice or 'good intentions' resulted in failed risk analysis and fallout prediction.
Two wrongs don't make a right, was hopefully something that your parents taught you when you where quite small.
The issue is that the FTDI driver is deliberately reprogramming a chip that is not theirs and for which they have no authorisation to do so. This is an unauthorised modification and illegal.
You cannot stick something in a license agreement that allows you to break the law, because the courts will hold that part of the license agreement null and void.
As many many people have said the right and legal thing was to simply stop working and post a message to the user that the chip is a counterfeit/clone.
Why put this down to malice and not down to a programming/QA issue?
If I am developing something, then my general approach is to test it against know factors and some edge cases I can think about. Counterfeit stuff screws with the whole programming and QA cycle, since they say they are the same as something I developed, act as something I developed, but fail in subtle ways I wouldn't have considered or tested for.
Maybe FTDI did do something intentionally, but I suspect it was an oversight, especially considering they pulled the update once reports were coming in.
FTDI will probably have to do three things:
- Test for the known limitations of counterfeit hardware (they can't test for the unknowns).
- Update the EULA to be clear of risk/
- Update the installer to warn against cloned chips and impact it may have.
That bar graph of a spike starting in 2007 would more likely be related to the release of the iPhone.
Except for the fact that the spike starts in 2004. Its an exponential graph.
Without the development of the iPhone it is hard to see an particular strong reason for Mac marketshare to start growing
OSX Version 10.3: "Panther". At that point OSX is far ahead feature wise of Microsoft's offerings, the complexity that existed 10.0-10.2 is over, the huge markup is over and the ease of use is high. Longhorn which will later be scaled back and released as Vista is years away. There is just no comparing the two systems in terms of what you get.
Second, hardware quality starts to fall through the floor on the PC side. The drop off in sales after 2000 had PC manufacturers cutting R&D, cutting parts quality and going into a spiral of chasing each other to the bottom in terms of build quality. The public had broadly realized this, while liking the lower prices. Apple's quality differences became well known.
The selection of software on a Mac is okish today, but in 2007 it was downright terrible
Nonsense. The selection was quite good. The Apple commercial market had recovered and the open source desktop market offered a nice collection of applications that as well. And for that matter Microsoft Office for Mac was quite good.
IN old england, the prisons became so over crowded they started using the rotting hulks of navy ships as prisons and as that became full they resorted to "transportation" which basically meant you get a one way ticket to help settle australia. (see book "the Fatal Shore"). Now that mars transport is about to approach feasibility ans Elon Musk says we need vast numbers of people for sustainable living I'm shocked the UK govt isn't sentencing these hackers to Transportation.
When it comes to telco it isn't nearly twice as expensive to hit every house as it is to hit every other house. It is much cheaper to have government organizing the digging up of streets and private property than to negotiate with the private and public landholders. Government can cut the cost per user enormously if they engage. I think the article is BS but your refutation is as well.
I don't buy it. Fiber's cheap
What makes you think fiber is cheap?
and our cities are plenty dense enough to support fiber to the home
That's fine. And if you wanted internet within cities then that wouldn't be a problem. But most people want to get to websites and internet services outside their cities. Which means they need to be using national bandwidth. If 100k people are consuming 1gbs of bandwith that's 100tbs going into the city often over hundreds of miles. So say 5 fiber links out 20-40tbs of capacity for often hundreds of miles. Then that gets intermixed with what the city itself is consuming.
We don't remotely have the technology to support that much bandwidth. So sure. You want to file share with the guy down the block the local cable company could put in fiber. But you want to gigabit+ bandwidth to everyhome that's unthinkably expensive.
But we don't, because lobbyists.
Yeah that must be it. The evil telcos don't want you to buy more of their product. The same banana importers are lobbying to block grocery stores from selling bananas by the bunch.
Why can't the USAians get the enjoy the same?
Because US population density looks more like Africa than it does like Europe and East Asia. We spread ourselves out which drives the cost of providing telco services through the roof.
How long have they been screaming for NFC
Mostly never. Apple customers were happy with Apple's position that Bluetooth did well what NFC did poorly. Android people were very upset that Apple people didn't have NFC.
Thx for the informative digression.
RHEL 6 (and its CentOS variants) are upstart, not systemd.
RHEL 7 is systemd though. Which means Cent is going to switch. And that means Facebook is going to switch.
Just admit you were wrong about them using it.
I know for a fact they are using it. They are using it for a backend I'm working with. Though it isn't terribly consequential to anything so it isn't a great piece of evidence, the system its on would run fine on Xenix.
"on hardware certified by RedHat Labs "
Also, Facebook's been rolling its own hardware for quite a while now, dude.
I included the quote. You missed the part where I said they were rolling their own hardware and the key point of who certifies it.
The point is that if you knew engineers working at those companies out here, you could have found out what they were actually running on by asking rather than making claims you can't back up.
Your claim from the start has been that systemd is unsuitable for server. Though your claim below is much weaker and something I would mostly agree with. So in terms of not backing it up you are disambiguating. You picked Facebook from my list:
a) They run CentOS. Cent OS is switching
b) They get their hardware certified by RedHat who is the single largest proponent of systemd.
I would say that's not opposite. But most importantly if you read the context I gave Facebook as someone advocating PaaS not someone advocating systemd. The PaaS vendors are the ones who care (and should care) about OS level components like systemd. I don't think clients like change.org should be concerned with the infrastructure at all. That's the whole point of DevOps it helps to further break the accidental bleed over between platform specifics and higher level software, which is what the whole enterprise Java movement was attempting to do for client / server.
Hi. I'm Jeff. My LinkedIn is the Homepage link next to my name. My apologies for not having it there previously.
Fair enough. Change.org DevOps architect is legit experience.
Well, we've already established that you've been lax about doing your research before making claims.
I think that's unfair and untrue. We just disagree about what constitutes a reliable source. I'm mainly interested in vendors because they have breadth you are mainly interested in engineers because they see things up close. The way you are phrasing it is unnecessarily harsh.
From my experience, given that for many of my jobs I've been the guy hired to clean up after a "systems integrator" with a cost sheet full of buzzwords and marketing woo came in and sold some magic beans to bigwigs who didn't listen to their engineers, your line of work tends to over-engineer a "solution", under-calculate cost of operations, and end up leaving a company with severe vendor lock-in disease and an engineering staff with a new solution that's outside of the team's core expertise, which leads to staff churn, high retraining costs for those that do stay, and dissatisfaction all around.
That's not about systemd but just to defend our guys:
a) I'd love to do accurate cost assessments where IT companies use a sane rate of interest and depreciate their IT infrastructure over 10-20 years. We aren't the ones who force companies to do ROI accounting as if their depreciation / cost of borrowing / interest rate were 400%. That's not the engineers either (they are mainly on our side about that one). Blame your finance guys not us. But ultimately if the customer is mainly focused on the 1 year or 3 year cost, then we build a solution to keep the 1 or 3 year cost low and often by letting it explode in the out years.
b) In terms of staff churn often the point of an integrated solution is to prompt staff churn i.e. displacement of the people. We get involved quite often because peopel are unhappy with what they are getting from their in house engineering staff. When the in house engineering staff is buying it they are generally picking a technology they are enthusiastic to use / learn or they already have the right skill set. If you aren't the ones buying it you aren't the customer.
c) Of course there is often vendor lock-in! We have long term ongoing relationships with the vendors where we work account after account after account. In a vague sense we are on the same team as the vendors. The vendor lock-in is often how we get the good price. But we (as a profession generally not individually) are happy to construct solutions with less lock-in if the customer (who remember is many times not the IT group) wants it. As an aside, in-house software creates employee lock-in which is for most companies worse.
You're claiming that all the companies you've namedropped thus far are your clients?
No I'm claiming I have DevOps clients. I named those companies as being large users of DevOps and PaaS. Netflix incidentally is a client. Though I'll be honest here, I don't give a crap about their software I only care about some of their handoffs to various local cable companies. I don't care what their software does as long as it uses X amount of bandwidth at the right times.
You can run a server on it, but it's not ideal. It removes many of the knobs and switches that experienced sysadmins and engineers used to get extra performance out of their systems. It adds appreciable layers of overhead just to do the same thing the parts it replaces has been doing for years. The developers themselves have shown an inability to think about it in a multi-system context. It presents a large attack surface because of the dependency chain its seeking out and building up. Maybe it'll be ready for primetime by 2018. I know I'll be hacking on it and submitting patches since the major vendors decided that selling new integration packages was more important than keeping their users and customers happy.
I agree with this except for the developers being unable to think in a multi-system context and this not being something driven by customers. I think I deal with more customers than you do. Getting away from knobs and switches that experienced sysadmins use and towards generic solutions and commoditization is exactly what the customers do want. You may not like that they want that, but that's the reality. Almost all customers love hardware abstraction, the more the better. And they are willing to use an extra 2-5% of boxes to achieve it.
You still think vendors matter. This ain't Windows.
This ain't the Linux of the 1990s when it was hobbyist OS for guys like me who couldn't afford an SGI or Sun at home and wanted a Unix. Linux today is a professional server OS. Systemd came out of RedHat. If vendors didn't matter Debian wouldn't be following in Redhat's wake on systemd and we wouldn't be having this conversation. Damn right vendors matter.