7,508 karma · joined February 28, 2013
Maybe you don't believe Durov's statement[0] about it. But is there any actual evidence anywhere that they've ever violated the secrecy of non-e2e private groups or messages for anyone? I've yet to find any.
It seems like you're advocating for Western powers to take a position, using either soft or hard power, on a war that already ended many decades ago. Sounds quite a bit like imperialism to me, and pretty far from being anti-war.
An anti-war position, at least from the perspective of a Westerner and Western companies, is more like, you guys lost, suck it up and stop asking us to intervene on your behalf.
I don't think AWS is particularly expensive at all. In fact, it's rather cheap at quite a few things if you know what you're doing and use the right services. I've got all my server backups going to S3, for which I pay a whopping penny a month. I also host a handful of Docker images on ECR for 7 cents a month - way cheaper than any other private hosting service I know of.
Now RDS, and the equivalent at every other hosting provider I know of, gets quite pricey indeed. IMO, you shouldn't bother unless you have pretty serious needs for reliability and speed. Apt install your DB server of choice on bare metal goes quite far. Or possibly pull a container of it into whatever you're using to manage containers.
To clarify, I do still think it's probably wise to prefer using a mutex whose LockGuard is not Send. If you're in an async context though, it seems clearly preferable to use a mutex that lets you await on lock instead of possibly blocking. Looks like that's what that Safina gives you.
It does bring to mind the point though - does it really make sense to call all of these things Mutexes? Most Mutexes, including the one in std, seem relatively simplistic, with no provision for exactly what happens if multiple threads/tasks are waiting to acquire the lock. As if they're designed for the case of, it's probably rare to never for multiple threads to actually need this thing at once, but we have to guard against it just to be certain. The case of this resource is in high demand by a bunch of threads, we expect there to be a lot of time spent by a lot of threads waiting to get the lock, so it's actually important which lock requesters actually get the lock in what order, seems different enough that it maybe ought to have a different name and more flexibility and selection as to what algorithm is being used to control the lock order.
> It said the AI alert was sent to human reviewers who found no threat - but the principal missed this and contacted the school's safety team, who ultimately called the police.
So the company AI reviewers correctly determined that there was no actual gun, and the police responded appropriately to a report by a person (the school principal) who claimed to have seen this student with a gun. The question then is what the heck is this principal doing? Why do they have access to this pre-verified AI information, and why are they going off and calling the police with this information before doing any verification themselves?
Well also, none of the coverage includes what was said to the dispatcher, but maybe they screwed up too - I would expect a dispatcher to question the caller in more detail about what's going on. Like, what kind of gun was it, is it in their hand or in a pocket or what, did they point it at anyone or threaten anyone with it or are they just carrying it around, etc, and such information could be used for a more appropriate police response.
These people don't seem to have much ability to discuss relevant subjects like what the actual reliability of lower-tier hosting providers is, the value-add to business and iteration speed of having a variety of extra services (SQS, DynamoDB, VPC, RDS, managed K8s, etc) available, etc.
Rails is still a good web framework within its limits. If you want to build a small, modest complexity web app with like 1 or 2 developers and under maybe 6 months of active development, modest traffic needs, etc, it's a good way to get everything up and running fast with best-practices for everything.
The lack of types may start to pinch some once you get an order of magnitude more developer-months into the app than that. Lack of overall speed, threading issues, and memory usage may be an issue once you get a few orders of magnitude more traffic. But while you're within those limits, I think you'll get features out on it faster than any other language or framework.
As they say, a lot more startups have died due to not being able to iterate fast enough in the early stages than from their traffic capacity, hosting efficiency, and bug count once they get into serious growth.
I've had substantial frustration with multiple tools all trying to redo my PATH for me, usually to make themselves the first thing. It's to the point where I decided to give up and hard-code my PATH in my .zprofile and get rid of all of the various tools' init scripts so that I at least can clearly see and control which things are in which order and not having a bunch of scripts trying to rewrite it all the time all with slightly different algorithms.
Maybe it would work if mise could manage all "tools" (various programming languages) as well as "tools" (actual CLI applications written in one of the languages and usually installed with that languages manager, like `cargo install`, `go install`, `uv tool install`, etc), though then it seems like it might be a pain to switch over to.
I haven't had any APN issues with regular SIMs in a while actually, but it used to be a common problem that would only sometimes auto-configure correctly. I've definitely had to google carrier APN settings and fiddle with them for a while to get text, MMS, and internet access working properly.
I also recently had an issue where I moved my US MVNO provider SIM to a new phone and it mostly worked, except for RCS. When I called them, they claimed my phone model wasn't compatible with their network, despite me already using it on their network for months. Apparently in their opinion SIMs should never actually be moved to a different phone. They offered to sell me a new phone, but I switched to a new carrier instead.
My opinion on unions is mixed, I suppose. They may be necessary in some times, places, and industries to compel reasonable treatment of workers. If such things are necessary, they're probably better than government intervention due to being much closer to the actual workplace. Historically, they have been responsible for establishing some good practices as standard in the American workforce. But they also have their bad sides. They tend to encourage an excessively antagonistic relationship between workers and management, cause pay and promotions to depend only on seniority rather than skill and work ethic, make it impractical to terminate workers who are ridiculously lazy or toxic, force everyone to take the same benefits whether they want them or not, enforce ridiculous rules about who can do what when, and other such things. They probably deserve at least some of the blame for the fall from grace of American automobile manufacturing due to things like being unwilling to accept greater factory automation even if it may lead to fewer workers needed, thus making the whole company less competitive.
I suppose in my ideal economy, I'd expect around 10-30% unionization, with the rest of the workers treated reasonably well due to a combination of market forces and threat of unionization. That's decently close to what we have in the US right now.
I do find advocates of it in the US to be ridiculous at times. Like, okay maybe unions are necessary and beneficial sometimes, but I think software engineering is about the least in need of unionization of any career in the modern world. But still some people seem to be obsessed with the idea of it.
Anti-monopoly regulation seems to be a mixed bag to me too, particularly in today's economy. Only 20-25 years ago, Microsoft was the big bad monster company, enough so that the US Government did start to look at using monopoly regulation against them a little bit. But the internet world and Google took the wind out of their sails better and faster than the Government could, and I think the tech world is better for it. FANG occupy similar economic space now, and I think it's likely that changing technology and market forces will again do a better job of knocking them back down a peg than the Government would.
Europe certainly doesn't lack smart and ambitious people, but I think those attitudes of who is allowed to be "on top" in society and what a good company looks like holds them back. That's a legitimate tradeoff that the people of Europe are free to make of course, but I disagree that it's the ideal way to organize a society.
> Just proof hire them for 6 months to a year.
As is common with most quickly tossed out "tiny fixes" to Socialist policies of excessive regulation, this makes the whole thing more complex and doesn't really solve the full problem for either workers or companies the way true free markets do. The only real "just" is just stop meddling with what everyone else does, let workers quit and companies fire whenever they want to.
> Your argument doesn't hold for someone that has worked for 10 years. If they were a bad hire; it's on you at that point.
Yes it does. It's not necessarily only that they're a bad hire. They could have the wrong skills or temperament or something for where the company needs to go, or the company could need to shut down a whole department or something. I don't know, the world has infinite complexity and possibility. I'm not smart enough to come up with everything anyone could ever want to do, and frankly, neither are you or anyone else.
> Easier planning life and reduce work anxiety for employees.
That sounds like a personal problem. I don't care to reshape national policy to cater to someone's alleged anxiety.
> It encourage companies to invest and train their existing employees since they're hard to get rid off.
Eh maybe, but many companies still do that now because good people are still hard to find. That's the better and more reliable way to do all of these things.
> It makes employees less scared to speak up or discuss problems.
Plenty already do that, I don't think it's much of a point. It's not really proven any more than the counter-statement that it makes employees more willing to slack off.
> It makes companies more cautious about reckless hiring if they're not sure about their economics.
That's exactly my point. I think it's good to let them "recklessly" hire if they think they can afford it. Some will get things right and grow huge, other will fail and those workers will be able to find new jobs more easily.
> Allows older workers to remain productive for longer, reducing the burden on the pension or unemployment system from people 55+ having a hard time finding new work for few years before retirement.
"Allow" how? They can already do that fine. Many companies value the experience of older workers just fine without the Government forcing them to do things. And I'd rather they have a comfortable retirement already set up from a robust investment market, possibly with a 401k or something like that. I don't want them to be dependent on either one company or the Government.
And intentionally saving this for last along with the end:
> If they're is such a massive difference we would see alot less globally competetive European companies.
> Finally, i must ask what the societal purpose of jobs and companies are. From a pure "numbers go up", there is a cost to worker protection. But id argue the society as a whole benefit much more from it than having a multinational IT company on the stock market. There is a balance to these things ofourse, but dismissing it outright is not fair.
"much less competitive European companies" is exactly what I do see, and you are also arguing that that's a good thing. Europe seems to have very little in the way of invention or growth pretty much since WWII. They haven't invented much new, and most of what they have invented has been eclipsed by more aggressive and nimble American companies. The European economy is still mostly dominated by the same large companies mostly doing the same things they've always done, sometimes adopting new technology long after American companies led the way.
I'm not dismissing anything outright. I've carefully observed the results of both styles of economy and I prefer freer markets. I like helping lead the way towards creating awesome things thanks to everyone's free will. It's not always perfect, but the market usually fixes things faster and better than half-baked Government policies.
When it's simple and easy to fire people, companies are a lot more willing to take a chance on hiring somebody they aren't 100% sure will be a good employee, and willing to hire a lot and grow fast knowing in both cases they can fire easily if needed.
I find it sad that so many people never think about the second and third-order consequences of what sounds like feel-good policies. They often end up being a net-negative for the people they were intended to help.
Source: My macbook has drained its battery flat while closed in my bag dozens of times. Then it just stopped doing that on an OS update. I still have no idea why.
On the other, I'm not sure if this is really needed. Most of this stuff already works fine in Ruby with Bundler. Did you know that Bundler already has a really nice syntax for inline requirements for single-file scripts?[0] Seems like a lot of people forgot. Installing Ruby hasn't generally been much of a hassle either AFAIK. Bundler also doesn't seem to have the Python venv problem - it works fine for keeping a bunch of gem versions around in the same Ruby install and only activating the specified ones. I think Gemfile and Gemfile.lock is what Python always wished they had. I guess more speed never hurt, but it never felt like bundler was painfully slow for me, even on huge codebases. So is there really a big win here?
Though I guess plenty of Python gurus probably feel the same way about the uv craze when their existing tooling works well enough for them.
[0] https://bundler.io/guides/bundler_in_a_single_file_ruby_scri...
That's not to say that I don't think it'll be able to handle it, just that it'll be a new challenge. I wonder if their current program of apparently trying to positively track every single moving object in range will survive that, or whether they'll need to figure out some algorithm to prioritize objects that are more likely to be of concern to it. And there probably are more than a few places where pedestrians are numerous and densely crowded enough that you can't positively track all of them, even with a bunch of LIDAR sensors.
Anti-gun propaganda.
Anti-gunners first started practicing lawfare against companies involved in the gun industry by suing them for crimes committed using products the companies were involved with, even though this is a ridiculous idea never applied to any other type of product. They do it because, even when the lawsuits are thrown out eventually, they are still very expensive to defend and most companies in the industry don't have particularly deep pockets.
Gun-rights advocates got laws passed in a number of jurisdictions clarifying that gun manufacturers are only liable for genuine flaws in their products. This has largely squelched these types of nuisance lawsuits.
Anti-gun activists don't like that, so they frequently spread false information that such laws prevent manufacturers from being liable for genuine flaws in their products. Despite such false claims, no law ever passed or proposed actually does this, and no law in this area has ever been repealed due to actually blocking liability for genuine flaws.
From all we've seen, the practical ability of AI/LLMs seems to be strongly dependent on how much hardware you throw at it. Seems pretty reasonable to me - I'm skeptical that there's that much out there in gains from more clever code, algorithms, etc on the same amount of physical hardware. Maybe you can get 10% or 50% better or so, but I don't think you're going to get runaway exponential improvement on a static collection of hardware.
Maybe they could design better hardware themselves? Maybe, but then the process of improvement is still gated behind how fast we can physically build next-generation hardware, perfect the tools and techniques needed to make it, deploy with power and cooling and datalinks and all of that other tedious physical stuff.
IMO, at least by the time I saw it, there were more than enough red flags raised to say that having it on HN before more evidence is available is only flamebait.