> As a skilled developer ? Shouldn't be that hard - plenty of options to pick from.
Maybe it used to be that way in the past, but not these days.
When I tried to go to Ireland a year ago, entering the country was impossible due to a multi-year long COVID travel ban. Schengen visas were useless — you needed a job offer AND a job permit just to enter the country.
I passed a bunch of interviews, received preliminary offer from one Irish company, but got rejected during security screening (I have never learnt why). Decided against trying again, because Irish job permit queue was 6 months long and growing.
This was a year ago. Right now it is hardly possible to leave Russia at all — leaving by ground is denied by Russian border forces (remnant of COVID restrictions, which has been repurposed to enact impromptu iron curtain). Leaving by air is impossible because most companies stopped flying, airspace is closed and foreign governments are mass-arresting leased aircrafts. As if that weren't enough, Russian government has enacted a total flight ban, effective starting today.
Even if you somehow leave a country and go to Turkey/Serbia/Georgia with piddly $10000, — then what? You'd have to quickly find a job, rent a place to live, and get a residence permit before you are booted out of country. All of that under extremely hostile conditions, such as not having a bank account and being unable to speak the local language.
Each glibc/ALSA soname bump can spell death to entire generation of binary software.
In theory, you can link libX11, openssl and other important libraries statically, but many developers don't do it, because of weird concerns about "security", "compatibility" etc.
Compare it to Windows, where libraries like kernel32, user32 and gdi32 remained stable for decades and statically linking to them is unnecessary by design.
Prompt engineering has always been a useful tool and still is. But a lot of problem, discussed here, can't be solved by any amount of fiddling. When Google does not even search long tail results, and there is nothing relevant in any of their "caches", doing prompt engineering only wastes one's time.
It appears, that there is some sort of fallback (?), that brings results of unfulfilled queries into a cache, but it isn't fast enough to respond to the user in real-time. Maybe Google should openly admit, that their resources aren't infinite, and offer to e-mail a better results once they are ready. Seriously.
> The security problem is being able to talk to the same X server as trusted applications
Use Ctrl+Alt+F<number> to switch into another VT and run a different X server. Run zoom in container there.
I found this a lot more convenient than messing with nested X servers and other types of X11 client isolation. Each time you leave an X server and switch to another VT, the clients perceive it like the monitor being turned on/off.
So you are saying, that US government controls such staggering amount of money, that even it's debt (denominated in it's own currency) is several orders of magnitude bigger than total worth of the richest person in the world? And that person is also many orders of magnitude richer than a mean citizen?!
Suddenly, Bitcoin does not sound so centralized in comparison...
but it is intended for dedicated file manager apps and requires an application to be manually reviewed by Google. Which hopefully means, that banks and other shady organizations won't qualify.
> a keyboard isn't something you should install without some careful consideration because they can be used as keyloggers
To be frank, Android should not allow input methods access to internet/filesystem in the first place. But that would have hindered Google's own keylogger, so...
You can't really get rid of connectivity check, because it is a part of public API. Applications use it to check whether a network has internet access. Android itself uses it to detect captive portals and prompt user to authenticate when network requires authentication/payment via a web page.
> On the other hand, having the wisdom of knowing what can be static in the first place? I don't think that it's something teached.
All traffic is static by definition. You are not modifying bytes when they are in transit to user. And you don't have to serve different bytes each microsecond just because users want to be "up-to-date". The network latency is usually around 40ms or so. If your website serves 1000s of requests per second, you should be able to cache each response for 10ms, and no one will ever notice (today this is called "micro-caching").
Of course, most webpages can't be cached as whole — they have multiple "dynamic" parts and have to be put together before serving to user. But you can cache each of those parts! This is even simpler if you do client-side rendering (which is why MangaDex abysmal performance is pathetic).
Then there are ETags — arbitrary strings, that can be used as keys for HTTP caching. By encoding information about each "part" into a substring of ETag you can perform server-side rendering and still cache 100% of your site within static web-server, such as Nginx. The backend can be written in absolute hogwash of language such as Js or Python, but the site will run fast because most requests will hit Nginx instead of slow backend. ETags are very powerful, — there is literally no webpage, that can't be handled by a well-made ETag.
Even pages, that need to be tailored to user's IP can be cached. It is tricky, but possible with Nginx alone.
Instead of "static" you are better off thinking in terms of "content-addressable".
The "non-west" countries are forced to regularly buy bespoke amount of US goods as official tribute to their suzerain [1].
Other countries might not have much better packaging policies, but if you want a war on plastic waste, US and Europe are some of best places to start it.
This sounds like it might help against DNS rebinding attacks, — at the cost of breaking interchangeability between DNS names and IP addresses.
Not sure, if such policy is a good idea, especially if the permission prompt automatically appears upon network activity without explicit developer intention. This will simply condition users to click "OK" without understanding what's going on.
Judging from reviews of hardware keyboard-video-mouse switches, they tend to work MUCH worse than Looking Glass. All modern GPU connectors are digital, so those KVM switches have to include a mini-gpu (usually a costly and buggy one). Also they end up re-implementing a complete HID support, because otherwise switching USB devices between hubs takes forever.
In nutshell, KVMs aren't worth their money because they have to re-implementing a lot of hardware already found in your PC.
Godot's FAQ makes some very good points, especially about GC, poor interop and inefficiencies language runtimes. But it feels like that reasoning focuses too much on the top interpreted languages (Javascript, Python, Lua etc).
Did Godot team considered using a compiled language like D with a bit of custom harness? Wouldn't customizing an existing object-oriented language be easier than designing a completely new one from scratch?
https://www.consultant.ru/document/cons_doc_LAW_348748/