> 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).
Platform means different things to different people but it should offer a standardized way of doing things that's well supported while allowing for customization by developers when needed (with less support when you step out of the golden path). It's a combination of software, processes and management buyin.
The way I see most "DevOps" teams working is they're just writing scripts that do whatever was requested without much thought about how sustainable that is, how company-wide policies can be enforced, or retrofitting improvements to other codebases... It's all very quick-and-dirt solution, one after the one until they end up in software engineering madness with developers complaining that things take too long or break easily while devops engineers complain developers don't know what they are doing. It's not a productive situation to be in.
I think platform engineering is just about having a systematic approach that gives developers more peace of mind so they can focus on actually coding features while giving the rest of the organization a bit more control points about how things are maintained. It's the 80/20 rule applied to devops, I guess. Just enough centralization.
I'm also very excited about platform engineering and I think it's a natural progression because, frankly, what people call DevOps these days is just a nightmare. God forbid the org has "distributed DevOps" a.k.a. do whatever you want in your team and when it's time to make a global change we will work with >20 different ways of doing something. That will be quick.
> what people call DevOps these days is just a nightmare.
I agree! It's taken on a, "you'll know it when you see it," kind of definition and it's hard to pinpoint what "DevOps" is and whether your organization is practising it.
And so I've often seen it become a veneer for the original "silos" it was meant to break down: those handful of developers who still want nothing to do with managing their code and services in production get to throw code over the wall and someone else gets to hold the pager and keep it running, make it fast, etc.
In other words, the company hires "devops" which becomes a new title for "system administrator," and everything stays the same.
Platform engineering, devops, it's all evolving... but some things never seem to change.
A platform team will eventually and quick fast become a bottleneck, especially if they offer abstractions over infrastructure, paas, saas etc.
Such a team is not any different than previous admin/infra teams. The operation model. When their offering breaks or is incapable, dependent teams wait or is stuck.
A team should be self sufficient and be able to decide for themselves how they cope with what they need to move forward in a sustainable manner. That means they should do everything themselves towards enabling there offering.
I have worked with so called CI/CD teams at least 10 times and it doesn't foster what devops is all about, which is essentially collaboration, mandate and responsibility for your software, inside a smaller team.
It comes down to how you organise and where decisions are placed and carried out. Something that reflects on centuries of command and control organisations where it has been around controlling and not enabling and autonomy.
I have worked a few places where the platform decision was taken on a broad spectrum, aws for example, and from there every individual teams could do whatever.
Every software/product team should be able to do everything they need to develop,test,deploy,secure and monitor their things. It works in a lot of places so of course it can work in a lot of other places.
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?
Personally (as someone who was high-school aged in the early 90s):
1. FidoNet BBSes were one early pre-Internet form ( https://en.wikipedia.org/wiki/FidoNet ). Even once the early Internet was up and running for some, some of us lived in countries/places where there was no access, and so the loosely-interconnected FidoNet BBS system was the first form of online group communications I was exposed to. There were even some gateways passing email and usenet newsgroups between FidoNet and the Internet towards the end. I had several local friends, we all ran FidoNet nodes, and we did use it for interpersonal communications at times.
2. Usenet - I used this a little bit in the mid-90s for true communication, but mostly that was highly technical in nature, e.g. IETF discussions on protocol development issues, etc. Also lots of using it to download binaries of course, but that's not really chat. I mostly didn't "know" the people I was interacting with, other than by online reputation.
3. IRC - From around 1994 onwards for me (when I finally had real access to the real Internet), on the EFNet IRC network (and a couple others, to a lesser degree). I spent many hours of every day lurking on EFNet's "#hack" channel and several others. There was a real sense of an online-first community, and then there were smaller and often private channels of people you knew from your real life (the other local hackers in your immediate community, or people you met at conferences, etc). I won't defend the culture as necessarily stellar, especially by today's standards, but at the same time, there was a sort of sense of community where it didn't seem to matter much who or what you were in real life, a sort of "if you're here, you're one of us" vibe. I think at least around 1994-1997-ish, IRC was pretty central to my social life (not all of it of course, but still!). Some of it was more anonymous in nature, but a lot of it was people I had met in real life or were even local friends of mine.
> 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!
> 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.
I would love to see iMessage available to people not on Apple devices.
However, I am not enthusiastic about a government defining what "interoperate" means in general. By way of example, I can think of many definitions of "interoperate" that would prevent the use of end-to-end encryption, or prevent upgrading the protocol and not supporting old versions, or prevent fixing security issues because some third-party client was relying on the insecure behavior, or prevent setting requirements on acceptable client behavior...
I want interoperability. I don't want to end up in a world in which, once you get large enough, it's impossible to innovate without slowing down and waiting for the slowest and most recalcitrant/adversarial folks who want to interoperate with you to catch up.
> 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.
I think this would create a whole new generation of tech startups in a stalled/captured industry.
fwiw in this case iMessage is easily funded by all the profit Apple earns off of iPhone/iPad sales, app store 30%, and iCloud subscriptions. It's not as if Apple is being forced to let millions of Android users communicate with each other for free over iMessage - Beeper exists because people want to communicate with Apple's customers, who already paid them money.
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.
Exactly :). The funny part is, the thing actually crashed! [1]
Why? Bad error handling in the software (primarily). What is the worst that could happen? An instrument saturate, a variable gets stuck at a value, but keeps being integrated, the spacecraft computes a negative altitude and thinks it'a below ground level (negative altitude) but is in fact in full descent and at 3+ km from the surface. Oopsie !
"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.
I sincerely find this to fall into the proscriptions against necromancy present in most ancient belief systems. The dead should not be made to speak the words of the living. And we should not create for ourselves any illusions about the completeness or finality of death.
It's not so much that it's a moral transgression as that it will undermine and corrupt our own understanding of what it means to be a living person.
Turns out, it doesn't mean much to be a living person. Ideas are what matter to society, not the individual that spawns them. When you kill a revolutionaire, you are only killing a man.
Depends on your framing I guess. I live life as a person not as a society, and so being a person is quite meaningful to me. I don't know what it would be like to be an entity that experiences it otherwise and I'm glad for that.
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).