The video store example is funny because iirc, it wasn’t until someone high up/very involved in government got bit by it. During Robert Bork’s failed Supreme Court confirmation, a reporter figured out he rented porn. Maybe it was something less raunchy / embarrassing than porn but either way, iirc, they got that law on the books fast after that….
The leak was inspired by Bork's opposition to privacy protections beyond those explicitly outlined in the constitution. [0]
On September 25, the City Paper published Dolan's survey of Bork's rentals in a cover story titled "The Bork Tapes". The revealed tapes proved to be modest, innocuous, and non-salacious, consisting of a garden-variety of films such as thrillers, British drama, and those by Alfred Hitchcock. [1]
The VPPA very much applies to online entities. Netflix can collect all the info it wants about you, but is very much limited in what it can share with external parties.
If anything, the law has given cover to shady walled garden business practices that would not have survived otherwise.
You read wrongly. The 2013 amendment merely allowed customers to consent to disclosure electronically via the Internet. Before then, it had to be in writing. It didn't change 18 USC § 2710's explicit application only to a "video tape service provider", and that is how the law still reads today.
I don’t know, I work for a massive (benevolent of course) corporation and it’s still pushy with Lock Screen ads, copilot, etc… and it definitely doesn’t just work. Maybe for the CEO it does though…
It might depend on how much your IT departements cares about customizing your setups. The efforts described in TFA for instance don't cover auto install scripts which are still free to create whatever local account is needed, provided it's done through the fleet management mechanisms.
Much of the scripts to "debloat" windows also rely on MDM entry points and overriding user preferences with higher privilege.
As you point out it's still a cat and mouse game but I assume they work OK. I tend to go the painful way and do most of it myself following instructions, as I'm not comfortable having these tools run as admin on a system. It's not that bad either.
I look back fondly to kid years when I took shots in the dark with IRQ and DMA settings on my boot diskette (so as not to mess with my dad’s settings) with autoexec.bat and config.sys (?), trying to balance out keeping enough available memory for the game but still keep the sound driver loaded. I don’t remember all the details, we’d guess a lot, but still learned.
Also, from the article, the nomad mp3 - now that’s a blast from the past.
Now I have a vague idea of what IRQs and DMA are, but I still have no idea what port 220h was.
Don't forget that the Sound Blaster card had a MIDI port to which you could connect a controller or joystick.
That was also a nightmare to configure, with calibrations on all axes, button remapping, etc. We were really motivated for pre-teens.
Great era. I remember being unleashed on the family computer and then attempting to neaten the file structure of our various games (Commander Keen, etc) in DOS and copying EVERYTHING into one central directory. Botched graphics display for the games that continued to slightly work...
The good old days when games requires Sound Blaster to play probably. It is too bad Creative Technology failed to transform out of Sound Card market. I remember discussing this in the early 2000s with a friend of mine in UK who is a Singaporean. He said Creative used to be pride of Singapore.
>> I look back fondly to kid years when I took shots in the dark with IRQ and DMA settings on my boot diskette
I look back on this fondly. I got some weird brand of soundcard that claimed SB-compatibility but was clearly different. I felt so proud the first time I got sound out of a game and no crashes. The same card was supported very well by Windows 95 a few years later.
My dad had an office PC that I secretly put a sound card and graphics card in. He would have gone mad if he knew I had done that to his work machine! I had very little idea what I was doing, but firing up Carmageddon 2 and having it run buttery smooth is something that sticks in my mind still.
It might have done, but that was roughly the age of the Voodoo 2, which kicked in only when needed for 3D and was literally disconnected from the monitor the rest of the time.
And he was the bane of fables to memorize and recite when I was a kid. Always struck me later on with ‘la cigale et la fourmi’ was always praised as a good lesson but that it was a bit cruel. I always preferred maitre corbeau avec son fromage.
Not to jump on your comment (since there have been quite a few other replies already) but just to add another personal anecdote: having been on the more senior end of a junior merge/deploy gone wrong and losing a Friday night or a weekend ping, I'm okay with an additional empty day throughout the week.
I've found that little things like that breed a growing resentment and stress that compounds, until someone wants to leave the company. Thursday night outage that I have to hop on? Much smaller deal than a weekend where I have established plans.
One can argue "why was the PR approved in the first place", but sometimes people make mistakes. It especially sucks when there are limited people that know how to troubleshoot and resolve the production issues with a system, even more so when the on-call individual may have not even reviewed the code initially.
All that said - I'd love to deploy as normal on Fridays! I've just found that the type of businesses I've worked at can wait until Monday, and that makes our weekends less risky.
I understand the article's emphasis on exercising good judgment around release timing, but read-only Fridays are not there for the people who generally exercise good judgment. If you are the sort of person/team that is likely to deploy late on a Friday afternoon despite the inherent risk, you are likely the kind of person/team who underestimates or ignores risks in general. This includes the risk of a given deployment, thus exacerbating the impact of your late-Friday deployments. It is therefore sensible to simply take the decision out of your hands.
I hate how people hear "read only friday" and decide to turn it into a CI/CD dick measuring contest.
For "read only friday" to have been a novel idea in the first place, you needed a starting point where conventional practice already was making changes live without stopping to consider the time/day of week.
I really suspect the detractors represent a workflow that would break (or at least introduce pain) if unable to push to production for a few days. So they have to give the hard sell on the benefits of continuous deployment.
Perhaps. But what's the risk-reward? No matter how good your CI/CD is, the risk is nonzero. Do I really need to ship this today and potentially open a can of worms this afternoon?
Charity's been running honeycomb.io, a SaaS startup with millions of dollars of revenue, for 9 years now, after being an early-stage engineer at Parse, a mobile backend-as-a-service startup that powered half a million mobile apps. She's talking about what she's made a reality at her company and its clients.
Deploy to what? Staging on every merged PR (commit to stg), and prod deploy on every commit to main? That sounds reasonable to me, and I've done some variation of it on most projects for the last 10 years or so without issue.
Yeah, what happens when Team A makes a change and Team B makes a different, seemingly unrelated change, and they both get merged and pushed... only to have a dozen customers discover that if someone is using Feature X that Team A just worked on and Feature Y that Team B just worked on while they have Uncommon Option Q enabled, then their backend process server will crash taking down their entire instance.
Who's fault is that?
Asking because I have been the customer with Uncommon Option Q enabled.
To counter the counterpoint.
Even if you are better at pushing to production than 90% of the rest of your industry it is still elevated risk and stress so you should avoid it for the sake of your employees. Productivity vs life.
If your counterpoint is to claim that you are just as stable pushing to production as you are when you don't, then I would just suggest you're delusional or lying.
This post is weird to me, because it sorta feels like it's attacking a straw man.
The idea the author seems to be advocating for is is that, while maybe you sometimes/often shouldn't deploy on a Friday (or even not at the very end of any workday), there should never be a stated policy in place that freezes deployments.
And yeah, I've been at places where they have freezes on weekends, holidays, right around the company's conference, etc. But they're never 100% freezes: if something goes wrong or is necessary, you just get a manager to approve it, and off you go.
I think the author's exhortation that developers should all be able to exercise their judgment to make these calls is a nice idea in theory, but falls flat in practice. Every developer will not always have all the necessary context in order to exercise that judgment. Even those who do, and generally have good judgment, will screw up sometimes because they are tired or are working under some sort of time pressure, or something.
Having a policy -- with some flexibility and exceptions allowed -- makes it easier to avoid those sorts of lapses in judgment. And that's a good thing.
But the whole article is just all over the place to me. The author starts by implying that people should be "ashamed" about identifying with a no-Friday-deploy policy, but then softens to the point of saying it's fine to have a personal policy of no late-afternoon deploys, no shipping big changes right before the weekend, etc. But that somehow if that's instead company policy, that's a bad thing. Nope, I don't buy it.
You’re also likely not interviewing for what you’ll be doing if you get the job there anyways cause who’s got time to update the interview scripts, right?
It's probably the parent corporation who would be liable for practicing medicine without a license and not the LLM (which is merely a software created by the said corporation).
Security (for vendor) from obscurity. AFAIK most of car owners cannot just buy the replace electronics for his car on used market so most of owners afraid of messing with proprietary computers in the car.
