Agree! I still have several (now discontinued) Philips 40 inch monitors, and that is the perfect size to do programming work. Very little scrolling needed while you work. But I would love to have a 40 inch in 4K+ instead of 2560x1600, why is no one making these? (I did get a Samsung 8K 50 inch, but that's too large for a multi screen setup)
I'm going to argue the other side: in Chinese cities like Chongqing they've seen a drastic reduction in crime after blanketing the city with cameras and monitoring technology.
Whole categories of crime disappeared. Women and elderly feel safe to walk the streets at night. No one locks their bike anymore in Chongqing.
I care about privacy, but I think we should be smart enough to work out a way to get some of those benefits without going full 1984. For example by having surveillance that can only be queried by an AI with very strong guard rails.
Admittedly, I live in a country with very strong democratic institutions, and I trust we would take action the moment something gets abused or surveillance overreaches. I would probably feel differently living elsewhere.
> I trust we would take action the moment something gets abused or surveillance overreaches.
The thing about turnkey authoritarian solutions is that once something happens it's likely too late to take action. However there are often alternative solutions that physically constrain the system such that substantial abuse is impossible without time consuming and expensive physical modifications. The traditional speed cameras in the UK for example.
Cameras, AI integrated at the edge, software that can't be updated remotely, the full stack publicly audited, that only output video data when a suspected violent crime is flagged. Something like that might work. I'm not optimistic such a solution would see much support though.
You'd also probably want a policy put in place in advance to quickly pull them down if certain criteria are met. But again, I'm not optimistic about the prospects.
Well I agree, and my hopes aren't very high of this actually happening. Our politicians tend to be clueless with anything tech related, their opinions calibrated by what they saw in Hollywood movies, where anything tech related always turns into "black mirror". (By contrast, allegedly over half the Chinese politburo has an engineering degree of some kind).
But we could start small, with just one neighborhood, a pilot project where the kinks get worked out and slowly scaled up. Getting permission for a small scale pilot shouldn't be impossible.
Everybody made that exact same "slippery slope to Nazi Germany" argument when euthanasia was legalized here. That was decades ago. There have been several attempts to broaden or narrow the scope of those laws and the democratic institutions did just what they were designed to do, making changes judiciously.
If you are worried about the slippery slope, then you are really worried that democracy does not work as intended. (And depending on where you live that may be a very reasonable worry). By the way, Nazi Germany was not really a surveillance state, perhaps you are thinking of East Germany?
> If you are worried about the slippery slope, then you are really worried that democracy does not work as intended.
Not really. That's a well established failure mode. People's perceptions can gradually shift as they become accustomed to the new way of doing things.
Personally I'd be less concerned about a slippery slope and more concerned about abrupt changes in policy. All infrastructure should be designed with the worst case scenario in mind. It's naive to assume that things will never get worse suddenly or that we will have plenty of warning or even a meaningful opportunity to react.
There's no way to deploy a system like the one you're describing without being abused for authoritarian overreach. It's simply a matter of time, and once it is deployed for authoritarian overreach, the only way back will be paid for in blood.
The article mentions .gitattributes but does not mention a super useful property you can put in that file: you can use it to specify that part of your repo should not end up on a production server. We have this line in our .gitattributes:
/test export-ignore
That means that when a "git export" happens from git to our production server it skips all test files. (In our case Capistrano does that, no additional configuration needed.) You never want test files on a production server and it saves disk space to boot. Normal usage is not affected, in development or testing you would always do a "git pull" or similar.
While this is a good feature, I fear most people aren't aware of git archive. Of the more basic CI tools I have looked at, I didn't notice any of them using git archive. Capistrano is the first I now know of that does this. Are there any others?
There is also export-subst that is also used by git archive to create an output similar to git describe directly in a file.
I'm not very familiar with deploy tools other than Capistrano, but I would think you also do not want to have the .git directory with your entire repo inside the working directory on the production server, so I assume some kind of "git export" must happen at some stage on most deploy tools? (Or perhaps they just rm -rf the .git directory?)
tangential, but deploys/builds that involve worktrees happen to neatly sidestep this since then .git is just a pointer to the real one. i use this to avoid having to otherwise prevent docker from wasting time reading the git info into the build context (especially important for latency if feeding local files into a remote image build)
… and put local African cloth producers out of business. The same happened with shoes sent to African countries by NGOs. Well intentioned, but local shoe manufacturers went out of business. The local population did not really benefit, because traders would get a hold of the free shoes and sell them on for just a bit less than locally produced shoes.
Profits = revenue - costs. Costs include depreciations and write offs of investments, and capital costs (what they pay to service debt), before you get to a taxable profit for accounting purposes. It's going to be many years before they pay taxes, if ever.
They do have to pay Value Added Tax on their sales in many countries (all of the EU), but not in most of the US. (The basis for Trump's claim that the EU is robbing the US. Sigh.)
> management ... literally just status updates and asking when things are going to be finished.
True. But there are many people whose productivity slumps unless they are asked for progress updates every day. You have to offset this against the people whose productivity slumps BECAUSE they are asked for updates every day. In large orgs with unknown quality of people I guess it's not impossible that middle managers add value.
When I worked as a strategy consultant in the Netherlands (albeit decades ago), the rule of thumb was that any organization that had not seen a reorganization for five years would accumulate at least 10% of dead weight. (Mainly due to very strict labour laws that make it very costly to fire someone.)
ASML has 44,000 staff total, not sure how many are managers, but the 1,700 number does not strike me as particularly ambitious for a reorg in a company that size.
I would like to be opted out by default. I'm worried at least one of those new services is going to get overrun by spammers, and if I'm opted in by default they could use the gateway to whatsapp to spam everyone else.
Not sure whether you would call this technical, but the difficulty lies in allowing third party access and still prevent spam.
The reason Whatsapp won out over competing services in the first place (over here at least) was that they managed to be both free and relatively spam free. All free alternatives quickly got subsumed by spam (even non-free SMS has a spam problem nowadays).
I guess if you count "silently blackholed by the other server with no recourse" an acceptable result then Apple / Meta can offer you that kind of interop too.
We've been storing jobs in the DB long before SolidQueue appeared. One major advantage is that we can snapshot the state of the system (or one customer account) to our dev environment and get to see it exactly as it is in production.
We still keep rate limiters in Redis though, it would be pretty easy for some scanner to overload the DB if every rogue request would need a round trip to the DB before being processed. Because we only store ephemeral data in Redis it does not need backups.
reply