For executables on Linux there are things like bubblewrap or firejail. One can also use a restrictive container. But those are strictly weaker than browser sandboxes.
The most secure way presently is to use qubes-os that allows to use a very hardened VM to run individual applications.
Modern solar work nicely in UK in May-August when wind is weakest due to long hours and cooler weather. However one needs more expensive panels that also work on a cloudy days.
Then in UK somebody calculated that a house needs 1MWh battery to last over winter using only solar panels that a typical suburb house can install. In 5-10 years that would cost 40K USD making it rather realistic to have. This ignore availability of industrial-scale wind which is the strongest in winter.
User namespaces significantly rise the risk of exploits and many setups disable them. One may argue that Docker should have used them when they were available, but that would break too many useful setups involving privileged containers.
Ah of course, we should not use userns because it might be vulnerable to some yet to be discovered vulnerability. The better alternative is to give full root access so we won't have surprises.
The full access to the docker socket from a user account is typically used on a development machine where malware has many other opportunities to become a root.
If oil and gas would not exist, then liquid fuel would be produced from coal. With the latest processes the cost of production is like 80 dollars per barrel, but with processes that Germans developed during WWII it was probably like twice of that in modern money.
In alternative universe that would be cheaper due to massive scale, but the era of very cheap liquid fuel would never happen. So electrical cars on big scale will happen much earlier. And given that coal is much more evenly distributed on Earth, one can speculate that there would be much less reasons for conflicts.
I dont think this makes sense, given how insanely much more polluting coal is. You have to burn massive amounts of coal to power the liquid refinery, 50% of the energy lost essentially in the conversion process. In addition to that liquid coal has double the emissions of regular oil. Air quality would have been a disaster.
EVs in scale would have maybe happened sooner, but they would have give us much less value, and I think in the end reaching current EV tech would most likely have taken longer than it did with oil and gas, just due to industrialization and technological innovation would progress much slower without oil and gas...
I think advanced green tech in general would have taken much longer time to develop also on an industrial scale when limited by coal only. Not to speak of human welfare would also have improved much slower.
What do you mean would have been? It was a disaster. Perhaps you are too young or insufficiently well travelled to have experienced the effects of burning coal in, say the UK in the 1950s and 1960s or in China even in the last few decades.
Without oil the push to solar and wind would also have been accelerated, probably.
What is it about oil and as that you think made it accelerate semiconductor R&D?
Yeah, my point was that it would have been even worse without oil and gas.
solar, wind and semiconductors all require a very advanced petrochemical supply chain. You simply couldn't produce any of this without products derived from oil and gas.
> You simply couldn't produce any of this without products derived from oil and gas.
That is simply untrue. Everything that is made from oil or gas can also be made from organic feedstock. I don't mean to say that it would be easy and it would certainly be slower to start with but it is certainly not impossible. Remember that the first plastics were made before the age of oil.
One currently used plastic that does not use oil or gas as a feedstock is cellophane [1], another is rayon [2].
In 1920 in Berlin there were more electrical taxes than gasoline one. But cheap gasoline killed electrical car industry.
Without that electrical cars would proceed to develop and batteries with high capacity would happen much sooner.
As for pollution it would not be that bad. Fuel would be expensive and cars with combustion engines would not happen on massive scale. There would be much more freight by trains and nuclear energy would be developed on much bigger scale.
You are talking as if oil and gas delayed the future, which I dont think makes sense at all.
I think we are underestimating all the derivatives we use from oil and gas here.
I think this is all very optimistic. I think not having oil and gas would have been a major setback to global progress I dont think it would have made us more advanced within batteries or electrical cars than we are today. And especially not even close to overall general global progress we have reached today.
ThinkPad X1 from 2 years ago was very solid and under Fedora everything but camera worked out of the box. And for camera issue I had to blame myself for not checking details of a specific model as Lenovo was offering at that time fully-Linux compatible model. It took about one and halve year before Linux fully supported it. And I already upgraded SSD on it which took less than 10 minutes.
The only complain is bad battery life. With several VMs running mostly idle it doesn’t lasts even two hours. But then I used beefy MacBook M2 at my previous work and with VMs it lasted only 4 hours.
For me the main advantage of Go over Rust is compilation speed. Then compared with Go Rust still rely on many C and C++ libraries making it problematic to cross-compile or generate reproducible builds or static binaries.
The minus side of Go is too simplistic GC. When latency spikes hit, there are little options to address them besides painful rewrite.
I've run into GC pauses, I think in many (most?) cases there is some class of bulky data that you can either move into slices of pointer-free structs (so the GC doesn't scan them) or off-heap entirely. The workload where GC is slow is also likely prone to fragmentation so whatever the language you'll have to deal with it.
Java with its copying GC deals fine with fragmentation albeit at the cost of more upfront memory. And even in Rust one can change the allocator to try to deal with fragmentation. But with Go there is simply no good options besides the rewrite.
Possibly in your specific application, usually there are a handful of options far less painful than a rewrite.
For the original issue of GC pauses, a narrow change is to move problem data to non-pointer-carrying types, or the bigger hammer of manually managed slices of those types. The second helps with fragmentation too. Some workloads can be split into multiple processes as a direct way to have smaller heaps. If none of those options are enough then off-heap storage lets you do whatever you want.
I do have some complaints about Go, but one of the big ones has been fixed since I last wrote much Go code and it seems like a fine choice for a lot of applications.
> For me the main advantage of Go over Rust is compilation speed.
Interestingly, Rust has quite good failed compilation speed. That's almost good enough. The usual Rust experience is that it's hard to get things to compile, and then they work the first time.
I've never been bothered by long compilation times, it gives me time to think about what the code should actually do.
To other people's usage patterns though, I imagine the group of people who don't do much with the type system rely more on running a built binary to see if it worked, which means they'll pay the full compile/link time cost more often.
Isn’t it somewhat easy to remove allocations in Go? I haven’t had to “rewrite” as such, but rather lifting some allocation out of loop. Am I misunderstanding the scenario?
Pauses are a problem with heap size and structure, not allocation rate, because the pause is caused by GC code that is O(heap size). Making garbage slower reduces the frequency but not severity. This is an issue with most GCs to some degree, there are phases of collection where the GC stops execution and the duration is relative to how much work it has to do which is based on how many objects and how much memory needs to be checked. "Concurrent" garbage collection is the approach of trying to reduce the pauses by doing more of the work while program execution continues. It's complicated and hard to get right, so Go's original GC was IIRC fully stop-the-world.
There are some fine points to the O(heap size), for example it's clearly unnecessary for the GC to scan objects that do not themselves contain pointers, and work is somewhat proportional to the total number of objects. Combining numerous small objects into manually managed slices, coming up with ways to make the most numerous items pointer-free, etc.
I learned a bit about this when an analytics workload I had ended up with unacceptable pauses (I think over 1 second), Go's GC is more sophisticated now but I think in any GC runtime you have the same considerations to some degree. Some of the best writing at the time was by Gil Tene, one of the principal authors of the C4 concurrent collector at Azul Systems, starting point here:
With backend serving many clients with widely varying performance profile of individual requests when latency spikes happen there is no particular hot loop. Just many go routines each doing reasonable thing but with a particular request pattern hitting pathological case of GC.
Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.
With Go basic stuff like url parsing or HTTPS support is written in Go and comes with the standard library. With Rust too many necessary things are just wrappers around C and C++ making cross-compilation and reproducible builds much harder to archive.
As for availability if CGO is ok, then calling C or C++ code from Go is not that hard. Also, there is always an option to just start C++ process if extra data copies are OK.
Has there been a lot of progress with ML in Rust? I don't really keep up with it because it seems like every crate ends up getting abandoned and I just gave up caring.
This entire thread is filled with people willfully lying about history like you are right now. It’s incredible to see. I can’t tell if it’s because this is a simple is vs ought distinction and you are having a hard to reconciling your ought with the is.
In his last book “The Dawn of Everything” David Graeber very convincingly argued that the idea of modern democracy came from Indian tribes in Northern America.
And it is also interesting how easily European countries went back to authoritarian or even totalitarian states given the opportunity. Yet US is more resilient and one explanation is subtle influence of Indian culture that still affects US.
As for technological advantage of Europe then 3000 years ago Ancient Egypt was way more advanced than Europe. 1000 years ago Arabic countries were more advance and 500 years ago China was more advanced. And Europe was lucky that China was focused on internal problems and not territorial expansion.
I think you have to be on drugs to think that American democracy came from Indian tribes. I grew up in the Midwest, so this mirror universe explanation for the origins of my country isn’t going to work on me.
>1000 years ago Arabic countries were more advance [sic] and 500 years ago China was more advanced.
Yeah real life isn’t your science fiction fantasy. None of this is true. I am aghast at how ostensibly smart people have, just in the last couple years, adopted a view of history that is completely at odds with the written record.
Eh. I wouldn't say only but it was the biggest advantage. The Europeans brought better tech and bad racism along with the terrible diseases. If they had established trade without disasters we might have seen the natives be very successful too.
If you have many cores and have the right optimizations in place the bottleneck for lz4 decompression is RAM throughput which is always going to beat whatever fancy disk setup you have.
But yes on the extreme end absolutely there's a point where lz4 stops making sense, but also most of us aren't trying to max out a 128 core postgres server or whatever.
Another option is WASM or WASM-style sandboxes if using another process is undesirable.
reply