Hacker News new | past | comments | ask | show | jobs | submit | unilynx's comments login

> 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


> navigator.locks.request("my_resource", async (lock) => {

This would be so much more readable with `using`

  {
    using lock = navigator.lock('my_resource');
    await do_something();
    await do_something_else();
  }
(https://github.com/tc39/proposal-explicit-resource-managemen...)


It doesn't actually feel more readable to me. I find the idea that the lock declaration sits at the same level as the lock content confusing.


It's readable if you're familiar with the RAII pattern which is used in languages like C++ and Go.


It's also similar to C#'s "using ...;" without a block. Syntax sugar there rather than RAII, but looks the same.


C#'s using can be used without a block. It disposes the resource at the end of a current scope.


I always felt that pattern was a bit too clever than it was a good design.


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.


Well, Go doesn't quite support RAII.

This syntax looks more like Python or Rust.


It's not RAII, but closer to dynamic-wind.


Yes, it sits at the same level to signify the lifetime of the lock.


Why can't we just `await` the lock call?

Edit: Nevermind, release of the lock is automatic when the callback resolves its promise. I get it now.


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.


   navigator whileLocked:'my_resource' do:{ :protected |
      protected doSomething.
      protected doOtherThing.
   }


You can probably wrap it to have that API


Sadly it needs a language feature that doesn't exist yet


What do you mean? You can definitely already wrap that into a Symbol.dispose-keyed object and use it via `using`


`using` is not a thing in JS


Uh, you are wrong. It absolutely is a thing and it has been in your browser and Node for longer than a year.

https://github.com/nodejs/node/pull/48518 https://github.com/tc39/proposal-explicit-resource-managemen...


s/yet/thankfully/. We don’t need it cause it solves no real problem and the solution is loaded with implicit complexity.


'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!


If it only weren’t for that crippled "using" syntax. On the other hand, though:

    const denialOfService = res => void navigator.lock(res);
I mean, one might write this just as well with the callback interface, but this is much easier to do accidentally.


> 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.


Yeah SIG_STOP or just ip/nftables DROP would be a much more realistic test.


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)


well in a way all processors commonly use them... as big-endian is also the network byte order


...x86 CPUs actually have special mov instructions now to load big endian data. Not sure since when though (on godbolt it needs `-march=native`:

https://www.godbolt.org/z/bWfhGx7xh

...without -march=native it's a mov and bswap (so not too bad either).


Looks like it was introduced with Haswell (2013). So it’s safe to use if you’re also compiling with AVX2.


> If I create a fork of a public repo on GH, I require a license to distribute it because a public repo can be forked or downloaded by anyone

Why?

The users that clone or fork your fork of the original repository are covered by the original repository's "license" GitHub grants itself, not yours.


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.


What would you expect the GDPR to say? This is allowed as long as the GDPRs requirements are followed


except that those instructions will be handed out by phishers


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.


Best way to solve problems is not to have them in first place, like getting a Linux laptop for doing Linux work.


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 like my laptop though.


Then use it as Apple decides it is in our best interest to do so, :)


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


Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: