> In 2004 you'd be shit outta luck trying to backup a mobile device as most were self contained and didn't interface to pc/mac.
True but ..
> Also mobile devices back then had limited storage, didn't have cameras, weren't Internet connected, etc.
which also means they didn't have a lot of data worth backupping
2004 mobile devices are usually either MP3 players or PDAs. Both synced over either a USB cable (or fancy infrared stuff) and were mostly just downloading from a PC. Not much was lost if the device crashed except your Bejeweled progress.
SEPA is not free - it's just often free for consumers (and likely until your bank considers your usage patterns to be 'too business like')
and it can't be free.. even though the systems might have no further marginal cost per transaction, banks still need to do anti-money laundering checks, and someone's gotta pay for that
Makes me wonder what part of the pattern you think is "too clever"? I think it is fairly easy to reason about when the lock is restricted to the encompassing block and automatically dropped when you leave the block.
It’s kind of a weird design that some of your variables (which you can define anywhere in the scope FWIW) just randomly define a critical section. I strongly prefer languages that do a
with lock {
// do stuff
}
design. This could be C++ too to be honest because lambdas exist but RAII is just too common for people to design their locks like this.
If you really wanted it to be at the top level you could probably turn it into an explicit `release` call using a wrapper and two `Promise` constructors, though that would probably be a bad idea since it could introduce bugs
Subjectiveness aside on what’s more readable… your proposing a new language feature would be more readable than an API design. To me, the MDN proposal is declarative whereas your proposal is imperative. And with my subjectiveness, JavaScript shines in declarative programming.
'using' fixes having to do cleanup in a finally {} handler, which you can a) forget, and b) often messes up scoping of variables as you need to move them outside the 'try' block.
It also creates additional finalization semantics for a using-ed value. Which has all sorts of implications. lock.do(async (lock) => {work}) is a similar construct - a scope-limited aquisition that requires nothing special.
Catch/finally not sharing a scope with try is a repeated mistake, that I surely agree with!
> So what happens when one of the servers is offline? Say I stop the US server:
> service nginx stop
But that's not how you should test this. A client will see the connection being refused, and go on to the next IP. But in practice, a server may not respond at all, or accept the connection and then go silent.
Now you're dependent on client timeouts, and round robin DNS will suddenly look a whole lot less attractive to increase reliability.
Yes, this can be tested by just unplugging or turning off a machine/VM with that IP address. Stopping a service is a planned action that you could handle by updating your DNS first.
class E can't ever be used on the public internet anyway. too many existing firewalls are already configured to drop anything with a source address in range 224.0.0.0-255.255.255.255 (class D and E)
Because if I didn't have a license then that would mean I would be liable for infringement every time someone downloaded it from GH. That's exactly why GH has the TOS that it has - so that nobody can be sued for just using GH when a rights holder uploads their own work to a public GH repo.
To mirror the sibling comment, where's the POSIX container/zone/vm whatever specification? If the BSDs and Linux can agree on a meaningful subset, macOS might actually follow
There isn't any in POSIX, then again, it isn't as if we now need containers for every executable for any magical reason.
Also, just like in the good old days, it isn't hard to have something dealing with HP-UX Vaults, Aix logical partitions, Solaris/Ilumnos Zones, BSD jails, macOS Virtualiztion Framework,....
Just listing technologies that sound kind of similar isn’t enough to actually answer the problems people want solved. The “good old days” were basically just people crying about being unable to have any of the features we have now because they don’t match up or differ in subtly different ways.
It's harder and harder to use Linux at work outside of bigger tech companies these days. Security standards like SOC2 seem fairly difficult to satisfy for Linux workstations without serious compromises. This is a damn shame because there are approaches to secure Linux workstations that seem pretty powerful but security standards now are prescriptive about what you must do to secure your systems, and for Linux that's going to mean paying for some subscription software that most likely only supports a couple of distros, and if you're lucky, they might support kernels from the _current_ decade.
I used Linux workstations for most of my entire career, at nearly every job. Seems like around 2018 something changed and now I'm going to have to fight to get a desktop that I feel vaguely productive under for every single job I get going forward.
Words of wisdom. I do not really have any dev related problems with WSL2 either. Normally I develop and debug on Windows and deploy to Linux as my code compiles and works natively on both. It is mostly C++ backends lately so I suspect I am in tiny minority.
I was responding to 'people insist on using Linux specific stuff instead of UNIX'. As far as I can tell there is no way to do containers without doing highly platform specific stuff. It would be very useful if the platforms worked towards a common 'more than chroot' thing.
As far as not really needing it, it's not like computers themselves are anywhere near the bottom of Maslow's pyramid, but that doesn't make them any less useful
True but ..
> Also mobile devices back then had limited storage, didn't have cameras, weren't Internet connected, etc.
which also means they didn't have a lot of data worth backupping
2004 mobile devices are usually either MP3 players or PDAs. Both synced over either a USB cable (or fancy infrared stuff) and were mostly just downloading from a PC. Not much was lost if the device crashed except your Bejeweled progress.
reply