> A key feature of a platform should be that the developers choose when a deployment happens.
Agreed. When I was on a platform team we wrote tools to take a process that used to be done by a deployment team (change a DNS record was a helpdesk ticket) and move it into a self-serve system (PR your desired DNS changes in, upon merge, the system deploys the changes), which kept audit happy because 'dev' wasn't touching 'prod' in the unfettered way SOC2 people stay up at night worrying about (even though Enron happened because of bad managment not Office Space but anyways), while still giving Devs effective control of when and where they wanted to make production changes, whether relatively ad-hoc or as part of a CI/CD pipeline.
Humans could approve the self-service PRs, or if a list of in-code rules had been fulfilled, the PR would be auto approved (and potentially even merged but everyone but us was too afraid to set that part up).
So I'm pretty (very?) young compared to most HN luminaries. I've never even started a company much less did something HN famous like writing the LGPL. But I love to hear these discussions.
I'd love to ask the elders this: when did you first start doing group chats, as in multi-user chat rooms with roughly permanent de-anonymized identities?
So, I was in jabber IM rooms in my first job, we didn't use cell phones, but there was an IT department chat, a companywide chat, etc.
Later technologies include lync/skype4biz, hipchat, teams, slack, and zoom.
Limiting myself more to the article's definition (mobile-first group chats), I'd say it was Google Hangouts, GroupMe, WhatsApp, then Signal, now its Signal + discord + FB messenger + all the millions of apps that just should be parts of libpurple / beeper.
But for those of you who remember eternal september, when did the group chat as those dot com babies like me know it first start out?
> The company has previously said that its practices do not violate antitrust law. In defending its business practices against critics in the past, Apple said that its “approach has always been to grow the pie” and “create more opportunities not just for our business, but for artists, creators, entrepreneurs and every ‘crazy one’ with a big idea.”
Tell that to Beeper Mini who had the crazy idea of growing the pie of iMessage users, following the original protocol seamlessly through adversarial interoperability.
It is quite debatable over whether Apple should be forced to allow another company to make money using adverse interoperability and server runtime costs etc.
In the same way it was quite debatable over whether IBM should be forced to allow another company (Compaq) to make money using adverse interoperability and reverse engineering IBM's BIOS.
I'd argue that the second debate was settled in the right way, and am partial to Apple being forced to interoperate as well. If you run a service with more than, say, 5% of a market, and that market has a network lock-in effect, you should eventually be considered a public service and have to interoperate.
Pidgin / Blackberry Inbox / WP7 homescreen / Matrix bridges and other services that unify incoming and outgoing text and binary messages for 1x1/group chats should be table stakes, not selling points. Email and IM, whether on PC, mobile, XR, whatever, vendor agnostic!
The Hacker News mic drop strikes again. I have nothing super substantive to add except to agree with your point and add that yes, it feels like work to put in the formal policies and procedures, but when the stakes are high enough (rocket to mars? its high enough), even the work that doesn't intuitively feel 'worth it' to someone is DEFINITELY worth it.
"It's a waste of time" is very often a fallacy, especially when the risk cannot be easily undone.
I (mostly mentally) complete the phrase "It's a waste of time" with "what's the worst that could happen?", and when I'm actually saying the phrase out loud, stare at whoever said that for 5 full seconds.
"Scary cloud things" like this are why I moved off of Dropbox and Onedrive years ago and got to a new normal of "syncthing all my main devices together" for file sync, then have Backblaze backup my machine that holds the linux ISOs etc. that I'm not necessarily wanting to have redundant storage space used for them at that time.
Now, the failures are my own fault, but at least I can do offline backups to HDDs and BD-Rs, and I don't have to worry about any of the cloud services (TM) messing with my data and me having little recourse.
Yes, I could do separate backups of the cloud things too, but at that point, that just adds 'cloud service' as an option to the first part of the equation:
cloud device storage / local device sync (on and off-site) / NAS
+ offline on-site backups as HDDs & BD-Rs
+ online off-site backups
Doing syncthing with local device sync is cheaper than cloud device storage (recurring costs) and NAS (fixed costs / hardware maintenance)
So I tried to click new map and drag n drop a few shapes from the toolbox into the map, but my mouse did not indicate that the map canvas was a place where I could drop the SVG icons.
So I tried to double click an icon, thinking perhaps I needed to have it be dropped on the map, then I could drag it around. That pinned the icon to the top left, but did not put it on the map.
So. I think this is cool, I played around with it for a bit, I'm too lazy to keep trying it, but the tool appears functional enough, pretty enough, and a great concept not used as much in online tilemap editors, so again, great job shipping!
I remember seeing that yahoo default option, then having to switch it back to Google (so this was long enough ago I didn't use DDG/Kagi), but I never noticed them remove yahoo outright as a search engine option. But indeed, it is gone.
The official addon (at least its username checks out, but might be a squatted username) appears to be [1].
I can't even comment on why Yahoo! was removed except to speculate that perhaps Mozilla no longer had a contract to give them trademark permission to include Yahoo in their default search engine list?
In the same way that using a limited medium like some oil paints, paintbrushes, and canvas to create images = the art of painting, there will become the art of hacking / abusing / advanced prompt engineering / pushing AI to do things that are close to or at its limits of capabilities.
A: Oh so your LLM generated an image of a spaceship cockpit, so what?
B: So what? This LLM was trained on nothing but tax records from 1929!
A: :o amazing!
So AI artists do not necessarily equal 'creatives who render images using AI tooling', they may instead be 'creatives who tease out novel outputs from AIs' or something like that.
Then again, this is suspiciously close to a 'what is art' conversation, so i'll stop here.
Ops is not peripheral to the job, ops is an essential part of the job.
The job is always to make that computer box there do X when I the paying customer click Y button. On the inside there is some algorithm design and logic that tells the computer how to do the job, and also there is some stage setting and lighting and camera setup to cue the computer on what, when, where, and why do the job (and write down who told it to do it).
In terms of classic 'developer writes features then leaves it to ops to actually make the code be useful to customers' (AKA specialization inside the software realm), the division of front-line soldiers vs logistics comes to mind here.
If you don't have a front line, the enemy takes the land and you lose. If you don't have logistics, you lose the front line to starvation / lack of ammo, and then you lose the front line, then you lose the war.
So if you are in strict operations, you may be the logistics side of that, and the front-liners may look down on you for not doing 'the thing', but if you weren't there to do your job, then they get to starve, run out of ammo, or do your job as well (aka becoming more generalist / end to end ownership / full stack SRE) as their previous job.
Reader: Ok smart guy, what's your solution?
I advocate to stop splitting the job of dev and ops into separate roles and doing the devops practices for everybody. We lose theorized competitive advantage but gain flexibility and more well-rounded skill sets so we really can call ourselves software engineers.
If you can code algorithms but not properly manage the lifecycle of your code after entering it into the source code file (testing, deployment, runtime, data migration, upgrades, decomissioning), you only have half the toolkit.
If you can do one or more of the other pieces but not do reasonable data structure and algorithm design relevant to the problem space, you only have half the toolkit.
We don't have residential plumbers arbitrarily split between vertical pipes and horizontal pipes...all the pipes are needed, so the plumber learns to handle both. Why did we let the 'expensive computer operators + cheap clerical roles' of the punch card era split up our profession today into 'devs' vs 'ops'?
> The root cause is probably the incrementalist approach we take to developing software.
I would blame the "unix philosophy" and "worse is better" approaches of the past, but I bet they were more symptomatic than causal, and their equivalents in other digital realms pop up all the time: IBM vs clones, unix wars, protocol wars, at various times its fights between 'official' (described as stuffy) vs 'pragmatic' (described as lax/crappy) definitions of stuff.
I'd hazard a guess that since (for those of us who are young and therefore spew confident sounding incorrect speculation like this comment) we still have so much of the old 'it works, ship it' hacker groups of the 70s in our past, then the overreach of the CASE / UML / XML fever of the late 90s which we have in turn overreacted against by going too far in the 'look its a containerized k8s pod running behind a reverse proxy that runs some react and uses leftpad to graphql your (must always be online) user information record in this headless electron because SHIP IT' direction.
PS: our historical 'its good enough' precedent didn't help, we've been trapped on 'very fast PDP-11s' for decades. Even BWK and the other forerunners of our modern C + unixlike stack weren't able to get us un-stuck from that stack and so plan 9 etc. failed to catch on. The Lindy Effect is a double-edged sword for sure.
Agreed. When I was on a platform team we wrote tools to take a process that used to be done by a deployment team (change a DNS record was a helpdesk ticket) and move it into a self-serve system (PR your desired DNS changes in, upon merge, the system deploys the changes), which kept audit happy because 'dev' wasn't touching 'prod' in the unfettered way SOC2 people stay up at night worrying about (even though Enron happened because of bad managment not Office Space but anyways), while still giving Devs effective control of when and where they wanted to make production changes, whether relatively ad-hoc or as part of a CI/CD pipeline.
Humans could approve the self-service PRs, or if a list of in-code rules had been fulfilled, the PR would be auto approved (and potentially even merged but everyone but us was too afraid to set that part up).