Does your friend or significant other have a Mac from work that is locked down so that changes can't be made? Any attempt to make a chance in System Preferences asks for the admin password, which you don't have. Maybe they are a teacher at a school with overly-zealous sysadmins? Maybe they work at an insurance company that... just kidding, no insurance company supports Macs.
Someone Who Isn't Me knows someone that has a Mac laptop and can't print to the home printers for exactly this reason. To print at home, they generate a PDF, copy the file to a USB stick, and walk it over to another computer that can print. That is ludicrous.
Now is your chance to fix this.
In macOS High Sierra, anyone can login as "root" with empty password. When asked for the admin username and password enter "root" as the user, then leave the password blank. Two this a second time and you'll unlock admin access.
Now is your chance to install that printer, change the screen saver settings, enable Time Machine, or whatever you have been wanting to do.
Apple will surely fix this soon. You probably only have hours or days to install all the printers and VPNs and other things you've been meaning to fix.
Oh, but don't break any laws or company policies. Certainly don't create an account with admin privs, or give the primary user admin privs. That is probably against policy and could lead to productivity.
There is a long and fraught history in Bitcoin of claims and counterclaims about who Satoshi is. I might as well confess that he is me.
I come forward at this time because Craig Wright claims to be Satoshi and I can't stand such intentional scammery.
If you read any of my pre-Bitcoin books, you'll see there are many pages where the first letter of each line reads "I am Satoshi Nakamoto" and "Someday I will invent Bitcoin". If you can't find the page that contains this, buy more copies of the books. You just haven't found the right one. Please use this link, since it includes my Amazon Associates code. Buy additional copies since each one might be slightly different.
Further proof: The first letter of the chapter titles of Time Management for System Administrators, it spells "tfrttttpseeda". I mean, what hacker doesn't know what that means?
Oh, I guess you aren't elite. My bad.
Now let me address my critics: Some say that this is just Tom trying to promote his books. Well, if that's what I was doing, do you think I'd write this on my book-promotion blog?
By the way... you can get a sneak preview of my next book: First, the new issue of ACM Queue magazine has the complete text of chapter 2 (free to ACM members, everyone else pays a small fee). Alternatively you can also see the latest complete draft on Safari Books Online which you probably already have a subscription to.
I read Ryan's article about why SHA-1 should be deprecated faster and why we should veto the proposed extensions. It is an excellent explanation of what's going on. I highly recommend it (and look forward to the complete series when he publishes it):
I feel like the cert provider's reply should be this:
Dear Ryan:
Screw you. You obviously don't understand the business we are in. We are in the business of PRINTING RANDOM NUMBERS AND SELLING THEM FOR UNGODLY HUGE SUMS. You're naive proposal may help the world, but how does that help us profit?
Here's an example, Ryan:
4
See? That was a random number. We just sold it to some duncehead that doesn't know the difference between a SHA-1 hash and a FQDN. For how much? A thousand dollars. That's right. ONE THOUSAND DOLLARS. We do that every few seconds and it (snoooooorts a big line of coke) feels so good!
Why did it cost $1,000? because we list the price as $48 but then upsold him on wildcards, EV (whatever the heck that is!?!) and a hella boat load of other things.
So let me tell you what we, the cert providers, think about your proposal to help the world or something:
Screw you. Screw you, the horse you rode in on, and your little dog Toto too!
Why? Because we're making money hand over fist and if you require us to change our code, we'll have to... well... pay a programmer to do that, test it, and verify it. That costs money. You know what "cost" is, Ryan? It's the opposite of me sitting in my executive office snorting coke.
So, yes, we've convinced Twitter and CloudFlare and others to do a lot of coding to work around our fucked up little system. Meanwhile, we will spend nothing. How perfect is that?
Yes, we could adopt SHA-256 for all certs and make the web safer but that would be something you'd do if we gave a shit. Yes, we'll adopt that awesome SHA-256 technology someday but ...and this is important Ryan... it won't be on 2016's budgets. Money spent today is a lot more expensive than money spent tomorrow. Why? Because there's a good chance I'll be out of here by then and it will be some other dipshit executive's problem.
Sure, in the meanwhile the NSA will crack the crypto and read everything people say on the internet. Do you think I care about that?
Sincerely,
Every executive at every cert provider
P.S. Here... have a thousand dollar random number on us: 6.
Ok, I'm sure that's not exactly what the cert providers are thinking. I'm sure it is pretty close. I don't think they'd actually give away a free random number.
Wait... you didn't know there are songs about DevOps? Hell to the yeah!
Best DevOps Song of 2015: Uptown Funk (Mark Ronson ft. Bruno Mars)
Uptown Funk is exemplary of good DevOps operations: It encourages being evidence-driven.
An important principle of DevOps is that you should base decisions on evidence and data, not lore and intuition. Intuition is great but only gets you so far. With a tiny system is is possible for a single sysadmin to know enough about it to make good guesses. However modern systems are complex enough that we must collect data, analyze it, and base decisions on that data.
This means we must also be willing to revert a change if the data doesn't pan out as we predict. That's the scientific method. We measure something, we do an experiment, and we measure again. Then we decide whether we keep the change based on the data. Of course, this requires that our systems are observable, which means the days of un-monitorable systems is long gone.
A more scientific way of saying this is DevOps insists that we prove our assertions by gathering empirical evidence.
So, why is Uptown Funk exemplary of this DevOps principle? We... duh! The point of this song can be summed up by this line:
Cause Uptown Funk gon' give it to you
Now let me tell you something. A lot of people don't believe that the uptown funk gon' give it to you. I understand. It might be difficult to believe if you have not experienced the uptown funk. I don't mean to brag, but I happen to have a lot of uptown funk-related experience. However, you shouldn't believe me just because I have so much experience.
Likewise, Uptown Funk's author Mark Ronson doesn't insist that you simply believe him. He assures you that if you use scientific principles, you will discover on your own just how right he is. In particular, he says:
Don't believe me, just watch
See? Total devops.
Sure, he could have said, "empirical evidence proves my assertion" but he states it more lyrically.
Let me quote the entire chorus to be clear:
Girls hit your hallelujah (whoo)
Girls hit your hallelujah (whoo)
Girls hit your hallelujah (whoo)
'Cause uptown funk gon' give it to you
'Cause uptown funk gon' give it to you
'Cause uptown funk gon' give it to you
Saturday night and we in the spot
Don't believe me just watch (come on)
Mark feels so strongly about being evidence-driven that he implores you to do so 3 times in a row!
Here's the music video:
Worst DevOps Song of 2015: Shake It Off (Taylor Swift)
Technically Shake It Off was released in 2014 but it won the 2015 Grammy and People's Choice Awards so I count it as 2015 too.
To be clear, I love the song from a music and dance perspective. In fact, I own a copy of the CD that this song appears on. By the way, the CD is titled "1989" which refers to the year she was born. [For those of you that were born in 1989 and are reading this, a CD is a way that people used to distribute music. Ask your parents.]
That said, I don't think it exemplifies good DevOps practice.
The main message of the song is simple: ignore the negativity in your life
Or, as she says it:
'Cause the players gonna play, play, play, play, play
And the haters gonna hate, hate, hate, hate, hate
Baby, I'm just gonna shake, shake, shake, shake, shake
I shake it off, I shake it off
Now if TayTay had a better DevOps background it would be more like this:
Teams should be encouraged to openly discuss disagreements.
File bugs. Don't suffer in silence. Amplify feedback.
Blameless postmortems for major outages.
Making that rhyme is left as an exercise for the reader.
Openly discussing disagreements is an important part of breaking down silos. When I was at Google I held periodic team-to-team meetings which would be open forums to discuss a process that affected both teams. Both sides would list out the steps in the process and point out the "pain points" and annoyances about the process. Many bugs and feature requests would be filed during these meetings and often bugs would be fixed in real time. Engineers would have their laptops open and would fix minor issues during the meeting.
Of course we need a way to deal with larger issues too. If enough haters hate, hate, hate, we should perform a postmortem. 2015 brought us a great book on the topic, Beyond Blame by Dave Zwieback.
Sorry, T-Sway, I can't just shake it off. We need to get to the bottom of this by finding the contributing factors.
Here's the music video:
So...
I hope you agree that we should be more evidence driven, that the uptown funk gon' give it to you, and haters should file bugs or otherwise open more productive channels of communication.
I hope to bring more DevOps music reviews to you in 2016.
Feel free to post your DevOps-related songs in the comments!
*Lately there has been a renewed debate over the use of encrypted communication. Terrorists could be using encryption to hide their communication. Everyone knows this. The problem is that encryption is required for ecommerce and just about everything on the web.
Should encryption be banned? regulated? controlled?
Lately there have been a number of proposals, good and bad, for how to deal with this. Luckily I have a solution that solves all the problems!
My solution: (which is obvious and solves all problems)
My solution is quite simple: Every time a website asks you to create or change a password, it would send a copy to the government. The government would protect this password database from bad people and promise only to use it when they really really really really really need to. Everyone can still use encryption, but if law enforcement needs access to our data, they can access it.
FAQ:
I've received a number of questions about my proposal. Here are my replies:
Q: Tom, which government?
Duh. THE government.
Q: Tom, what about websites outside the U.S.?
Ha! Silly boy. The internet doesn't exist outside of the U.S. Does it? Ok, I guess we need a plan in case countries figure out how to make webpages.
For example if someone in Geneva had the nerve to create a website, they'd just turn the passwords over to their government who would have an arrangement with the U.S. government to share passwords. This would work because all governments agree about what constitutes "terrorism", "due process", and "jurisprudence". Alternatively these Genevaians could just turn the passwords over to the U.S. directly. They trust us. Right?
Q: Tom, what if the government misuses these passwords?
That won't happen and let me explain why: There would be a policy that forbids that kind of thing.
If they have a written policy that employees may not view the passwords or use them inappropriately, it won't happen. I believe this because in past few years I've seen CEOs make statements like that and I always trust CEOs. I believe in capitalism because I'm no dirty commie hippy like yourself.
Q: Tom, how do we define when the government can use the database?
Dude. What part of "really really really really really" didn't you understand? They can't just really really really really need to use one of those passwords. They have to really really really really really (5 reallys!) need to use it!
Q: Tom, what if someone steals the government's database?
Look, the government has top, top, people that could protect the database. It would be as simple as protecting the codes that launch nuclear missles.
Q: Tom, doesn't the OPM database leak prove this is unworkable?
What? Why would the government name a database after one of the best Danny Devito movies ever? Look, that movie was fictional. If you aren't going to take this debate seriously, stay out of it. Ok?
Q: Tom, wouldn't this encourage terrorists to make their own online systems?
Dude, you aren't paying attention. They'd be required to turn their passwords over to the government just like everyone else! If they don't, we know they are terrorists!
Conclusion:
Hi. Thank you for reading this far.
Obviously the above proposal is not something I support. It is a analogy to help you understand that the FBI and other law enforcement
organizations are proposing. When you hear about "law enforcement backdoor" legislation or requiring that phones be "court unlockable" this is what they mean.
The proposed plans aren't about passwords but "encryption keys". Encryption keys are "the technology behind the technology" that enables passwords to be transmitted across the internet securely. If you have a company's encryption keys you can, essentially, wiretap the company and decode all their private communication.
Under the proposal, every device would have a password (or key) that could be used to gain access to the encryption keys. The government would promise not to use the password (key) unless they had a warrant. We'd just have to hope that nobody steals their list of passwords.
Obviously neither of these proposals are workable.
This debate is not new. 20 years ago FBI and NSA officials went to the IETF meetings (where the Internet protocols are ratified) and proposed these ideas. In 1993-1995 this debate was huge and nearly tore the IETF apart. Finally cooler heads prevailed and rejected the proposals. It turned out that the FBI's predictions were just scare tactics. None of their dire predictions came true. "Indeed, in 1992, the FBI's Advanced Telephony Unit warned that within three years Title III wiretaps would be useless: no more than 40% would be intelligible and in the worst case all might be rendered useless. The world did not "go dark." On the contrary, law enforcement has much better and more effective surveillance capabilities now than it did then." (citation)
We must reject these proposals just like we did in the early 1990s. Back then most American's didn't even know what "the internet" was. The proposals were rejected in the 1990s because of a few dedicated computer scientists. Today the call to reject these proposals should come from everyone: Sysadmins, moms and dads, old and young, regardless of political party or affiliation.
All the encryption lingo is overwhelmingly confusing and technical. Just remember that when you hear these proposals, all they're really saying is: The FBI/NSA want easy access to anything behind your password.
If you ran a Novell network, especially in the late 80s or early 90s, I hope you watched The Late Show with Stephen Colbert last night when he interviewed Steve Carell and talked about their brief work for Novell.
Bloggers who make stupid, attention-getting, predictions will not be held accountable when those predictions don't come true.
Windows-only enterprises have started buying Apple laptops to run Windows 10 due to the lower repair rate of the higher quality hardware. This trend will increase and Apple will run a marketing campaign to take advantage of the trend.
The battle between Docker and CoreOS to define the container format of the future will stall the industry as it gets more and more nasty. If you thought VHS vs. Betamax was bad, or that AT&T vs. BSD Unix was bad, this will be 100x worse.
The Microsoft container equivalent of docker will create more confusion than anyone could have expected.
Sadly the trend of encouraging girls to get interested in STEM at a young age will dissipate moments after the media spotlight goes away.
At least one company will claim to sell a "DevOps Appliance" that you can plug in, press the "on" button, and "have devops at your company".
I will not make fun of a company for marketing to my employer's WHOIS contact.
The industry that makes and sells bloated, over-priced, shitty, software development tools (the ones that have caused many of the problems in our industry) will repackage those tools as "DevOps" and make a lot of money doing so.
"DevOps is more than Release Engineering" will be the theme of at least one DevOps conference.
Real products announced on April 1st will be dismissed as jokes... again.
Google will cancel the following projects: Sites, Code, and... probably a lot more too.
By December 2015, Tom Limoncelli will decide not to do another "Predictions for next year" blog post.
These are my predictions for 2015. I wish all my readers success and happiness in 2015.
One of the DevOps goals you often hear about is "improved cycle time" for releases. What that means, basically, is speeding up the time from when a developer writes a line of code to when it is in production. The opposite would be writing code for a release that doesn't ship for a year or so (common in shrink-wrapped software). You often hear about teams bring their cycle time from months to days, from days to hours. Etsy brags that they've gotten it down to minutes. The benefits to reducing cycle time are well documented.
Well I have a technique that reduces it to a cycle time that is faster than minutes. Faster than seconds! It is absolutely instant. This is not even a new technique! It was common in the 1990s!
It's called "letting the developers edit code directly on the production server". Edit. Save. Boom! Code is in production. Thank you. #dropthemic
Every tech blog, news site, magazine and newspaper is writing about Google Glass. Half are saying good things half are saying bad things.
But there's one thing they all agree on: Mentioning Google Glass in a headline gets you readers.
You're reading this. Right? I bet a whole lot of you don't always read my blog but you are reading this post, right?
Writing about the success or failure of Google Glass is fantastic for many reasons:
It's low cost. You don't have to spend $1,500 on one. Just read other people's blogs and repeat what they've said, speculate, or just make shit up!
You are automatically correct. The product hasn't been released yet. Nothing you say can be "wrong" right now. Say that the actual sale price will be $10 million dollars or ten cents. You win! They, that's a good idea, actually. Someone should write a blog post saying they heard the final price will be ten cents! It isn't a lie, because you read it here. Just think of how famous you'll be for writing such an article!
When you are proven wrong, nobody will care. When Google Glass actually ships nobody is going to go back through all the articles written now and see who was wrong and who was right. If someone were to do this, those that were wrong aren't going to be fired or anything. It works this way outside of the tech world too! Heck, every person I saw on the Sunday morning political pundit shows last weekend has been proven wrong on whether Iraq had weapons of mass destruction, or wrong on the housing bubble, or wrong on TONS of things. Yet instead of banning them from ever speaking on economics, politics or foreign policy people like David Gregory just keep inviting them back! The tech world is even worse. Search around and see who predicted (in some cases vehemently!) that any of these products would fail: iPod, iPad, Android, Linux, the mouse, graphical user interfaces. Now take that list of authors and see which of them are still fully employed. All of them! Heck, I still remember John C. Dvorak mocking the Amiga for having multitasking... a feature he claimed nobody would want and nobody could use because "computers only have one keyboard". People still hire him! (I'm sure he never runs two programs at the same time because, he's like... consistent.)
Everyone else is doing it! Look! Now even I'm doing it! And yes, Mom, if everyone else jumped off a bridge I would too. The bridges in our neighborhood are all pretty darn low.
So take my advice: Mock it or praise it, parody it or deify it, make shit up or do actual research. Whatever you do, just write about Google Glass.
I know I plan on doing it.
P.S. Can I borrow someone's Glass? Please? I haven't tried it yet.
We are approaching the time when we will be able to communicate
faster than the speed of light. It is well known that as we approach
the speed of light, time slows down. Logically, it is reasonable to
assume that as we go faster than the speed of light, time will
reverse. The major consequence of this for Internet protocols is
that packets will arrive before they are sent. This will have a
major impact on the way we design Internet protocols. This paper
outlines some of the issues and suggests some directions for
additional analysis of these issues.
What makes some April Fools RFCs so good is that they are scientifically accurate. Currently internet protocols do need to be able to deal with packets arriving out of order (it can happen for many reasons). However the situation where replies are sent before requests has not received enough study. This RFC has some excellent analysis of just that.
A book of all the funny RFCs though 2006 can be purchased at www.rfchumor.com. It is the perfect gift for the geek that has everything. It makes a great book to leave around the office or home for casual perusing.
First was January. This was followed by February which transitioned rather abruptly into March. April followed, as did May. June, July and August were next, in that order. September came and went. October followed September, just as it has for as long as I can remember. Soon it was November and lastly December.
How do you demonstrate that your ISP is crap? Implement RFC1149 (IP over Carrier Avian) and show that the ADSL line being provided is "slower than a bird"! That's what people in South Africa did to embarass Telkom. Telkom has not yet commented.
SANTA CLARA -- Sun Microsystems, a small "Silicon Valley" startup finally achieved
it's goal of being acquired by a larger company this week. They have
been purchased by Oracle.
Most startups plan their exit strategy
as either being an IPO or being acquired. Sun's unique strategy was to
do both with a 23-year gap in between. This long, painfully slow,
strategy included years of selling their products to big name Wall
Street firms, developing cutting edge operating systems and
microprocessors, convincing the entire world that RISC is better than
CISC, and blowing it all by ignoring the rise of cheap x86-based PCs.
Sun is also reported to have invented "the dot", an enabling technology
that precipitated the "dot com" revolution.
The purchase by
Oracle surprised and stunned industry observers that had been on
vacation and hadn't been paying attention to anything for the last few
months. Said one analyst on vacation in the Bahamas, "When I left for
holiday I heard IBM was going to snatch them up. Whatever happened to
that?"
The original founders, Andy von Bechtolsheim, Vinod
Khosla, Bill Joy, and Scott McNealy, were excited to make the
announcement at a press conference in Mountain. Now that they have
completed their first startup the entire world is watching to see what
they do next.
Time:
Friday 09:15 - 10:15 Location:
Abbey Room Abstract: I call it my billion-dollar mistake. It was the invention of the null
reference in 1965. At that time, I was designing the first comprehensive
type system for references in an object oriented language (ALGOL W). My
goal was to ensure that all use of references should be absolutely safe,
with checking performed automatically by the compiler. But I couldn't
resist the temptation to put in a null reference, simply because it was so
easy to implement. This has led to innumerable errors, vulnerabilities, and
system crashes, which have probably caused a billion
dollars of pain and damage in the last forty years.
In recent years, a number of program analysers like PREfix and PREfast in
Microsoft have been used to check references, and give warnings if there is
a risk they may be non-null. More recent programming languages like Spec#
have introduced declarations for non-null references. This is the solution,
which I rejected in 1965.
The Complete April Fools RFCs (edited by myself and Peter H. Salus) includes one RFC that, it turns out, was not a joke. The book reprints all the April Fools and various "funny" RFCs and includes commentary not available online. And, err, umm... we recently learned that it includes on RFC that was not meant to be funny at all. We apologize if this has created any confusion.
April Fools Day is only 2 weeks away. I've seen some well-executed pranks played at work, and some that ended up in people getting fired.
The times people got fired often involved violating corporate policies, such as forging email from important people. I once saw a person forge email from a manager... oh, I won't finish the story, that's enough of a "no no" at most companies. Of course, if they had warned the manager he could have been involved and it would have been even funnier.
We once convinced a manager to email out a new data storage policy: Since the voice mail system deletes messages that are more than 10 days old, why not do something similar on our NFS servers? Certainly a file that hasn't been used in 10 weeks can't be too important. Imagine how convenient it will be to have your home directory automatically cleaned this way? Most everyone thought it was funny, except one person that was very embarrassed when he took his complaint to the VP, who had a much better sense of humor.
The RFC documents that define how the internet works includes many fake documents that are hilarious. www.rfc-humor lists them all. This includes the famous RFC for how to send TCP/IP packets over carrier pigeon.
Peter H. Salus and I compiled all the funny RFCs and put them into a book. Why sell something that you can get for free online? Well, first of all we added commentary, some of which is written by famous industry folks. Secondly, it's nice to have all the RFCs in one place. It looks great on a coffee table or in your office. (Oh, and you get to see the brilliant cover design that I did.)
You can still order it in time for April 1st. Makes a perfect give for the geek that has everything. Order today!
My solution is quite simple: Every time a website asks you to create or change a password, it would send a copy to the government. The government would protect this password database from bad people and promise only to use it when they really really really really really need to. Everyone can still use encryption, but if law enforcement needs access to our data, they can access it.
