The challenge for Crystal is that we also have TruffleRuby which gets you the elegance and Ruby interop. To me Crystal feels like it's at the same time too different to Ruby to benefit from the similarity and too similar to create its own viable niche.
HN is full of cynical comments like the above. We should be celebrating people trying things and doing things differently... I can almost guarantee you that the person who posted this cynical comment is not working on anything particularly relevant or useful.
My message to the HN community: HN is literally bankrolled by YC. If Crystal doesn't deserve to exist because other languages exist, why exactly should I care about your bullshit uber-for-dogs startup, or whatever not particularly original AI crap you think you're changing the world with these days? Get real. If you want people to be open to your ideas, maybe you ought to make an effort to be open to the ideas of others, and cultivate a climate where discussing different ideas is possible. Don't treat every HN post as an opportunity to opine on how you think the work of other people is flawed.
While you are right in that it is impossible to verify they work as advertised, it is not impossible to detect certain categories of failures. Like only generating values 0-255.
You could choose to detect small keys, but my understanding is that implementations entirely eliminate the issue by only searching factors with leading bits set (i.e. large numbers).
In my country we have people, lots of them, that would prefer to forget that renewables forget and to massively build out nuclear to meet demand. In that situation it makes sense to bang the energy cost drum. Yes, obviously the network needs to be kept running and that may take some added nuclear and investment in the existing hydro plants, but at the end of the day a sizeable part will going to be renewables as it is so much cheaper.
Centralized energy infrastructure tends to be a military target. Russia targeted Ukraine's nuke plants right off the bat. The US appears to be losing to Iran one strait, pipeline, refinery, or tanker at a time. The neat thing about solar is that it's not cost effective to shoot at--you're gonna spend more on the drone than your enemy is gonna spend replacing that panel. All of the things nuclear has going for it also make it a juicy target, and I'd rather pick up pieces of bombed panels than pieces of bombed reactors.
So if you get tired of banging the energy cost drum, consider a fill or two on the adversarial resilience drum.
Or if you prefer, consider resilience in the face of a heat wave. The fear that maybe the power will go out mid-disaster... it's just not actionable. That changes with a distributed system: you can channel it into making sure your house's or your neighborhood's battery is up to the task.
Your enemy doesn’t need to bomb the solar panels from a solar plant, they can just target the grid connection instead.
Unless you make rooftop solar + batteries with variable rate accessible for everyone (like Australia is said to have done), then yeah there will be no easy target.
But even then, your enemy could still target your grid stabilization infrastructure/peaker plants and make those who were not able to afford batteries lose power.
I wish grid operators could have some sort of remote control/feedback of “smart residential inverters” to be able to stabilize the last mile of the grid independently, maybe through a lora mesh or whatever their meters use.
Right, bombs are for when every $1 you spend on the bomb costs your opponent $1000.
If you're targeting many many instances of cheap decentralized infrastructure that doesn't take the whole region down when hit, it merely degrades slightly, then you're looking at something like $1:$1.
At efficiencies like that you might as well give up and resort to diplomacy.
Questions like this are easier to answer if you specify which problems you refer to. They have fixed a ton of issues since it was added to 22.04. If the issues you complain of is fixed or not, that is impossible to answer without more information.
My biggest issue is that I cannot start a snap program, e.g. firefox, and allow it to access different mount points than the one used for snap.
I know there have been partial fixes and workarounds, but if they change what it means to run a program in Linux and unexpected things happen, then I consider that broken.
Also, when I use VNC and xeyes works, then I expect any X11 program to work. Except, this does not always hold for snap based programs somehow.
These two points together make snap unworkable for me.
There is a flag to install a snap in classic mode, which I think would allow it more access, but I've not seen more fine-grained control than that. Perhaps it exists, I have not had a reason to look.
As for X11, I'm on Wayland and wouldn't expect xeyes to work. What X11 programs still is used seems to work fine in Xwayland, but I don't use VNC so I don't know how they interact.
So I don't know if these are solved, sorry. I suppose I have simpler needs.
Part of that is much of the point behind snaps (and just as true of flatpack for that matter) - once applications are put into sandboxes many things break. And while it is often easy to erect walls against unwanted use it takes a lot of thought building abstractions that let people do what they need in a controlled way that don't leave the system as open when compromised.
But yes I agree, it is definitely a big change compared to how things traditionally have worked. The question is if it is a necessary direction.
Well, if access to my filesystem stops working as expected, then I'm sure many people would agree that is not a desired direction ...
Linux has traditionally used the model of: users are suspect, applications are trusted; of course you can ask questions about that, but don't flip it upside down while breaking stuff. For example, I would probably be OK with it if they added a popup asking me to set permissions. But instead, it just breaks.
reply