h0l0gr4ph1c
h0l0gr4ph1c on Hacker News
so the firing party has an active homing beacon, aimed at you, just before they are about to fire? hmmmmmmmmmmmmmmmm yep no problems with that approach at all
If they got in this far, what else did they get access to? How long have they had access?
Saying its only a db *that they know of*.
What about the software repositories that they host somewhere?? Did the admin have access to that?
This is pretty major....
A generation is generally defined as 20 years. So you mean 3.5 generations i guess?
On another note, have you contacted facebook to get the data removed from their servers?
Rust is a language that does things different to other languages because it is a better way. I challenge you to do the same with Async. There is a different better way.
By opt in I mean I can opt in to using an executor if I want async. If I don't code still works and is might not be as performant.
Couldn't you have made another hard constraint to make async code work as normal if the programmer wanted?
I actively choose libraries that are non-async. I don't want to use the programming model.
If aysnc could work like regular blocking code , if we want, and async code when you want, I think rust would be in a better place.
Just because you can do something doesn't mean you should.
yes sorry, those were rhetorical questions. Your point about asking you fail to see why not using a blocking executor to deal with the async code. My problem is with needing the executor at all. I must have skipped a couple of you previous pints in this thread. Apologies about that...
Maybe we should start trying to think about async as being something can use if they want and ignore if they want. Code being async compatible rather than async required.
> "Using a proper, single-threaded executor and running it on the current thread seems like it would work, yes. (To be fair, I also feel like just having the sync version of a Python API call "trio.run(self.equivalent_async_api)" would probably also work, and I don't totally follow why that's insufficient....)"
Why do I need all this other bloat just to run a function? Why can't I just run the function?
Complexity kills code. Being able to reason about what your code is doing, is FAR more valuable to me than async. Having tokio act as my runtime and switch tasks as it sees fit will be debug hell.
The problem I see is the current async story is opt-out. It's use async or go find something else. Async should be opt in. As in, the code works regardless of an async runtime, async is added magic if you want it, but it will run like normal single threaded code if not.
IIRC our system of time is more so aligned with midday rather than midnight. As that is when the sun is at its highest point in the sky, which allowed us to create a common point between timezones.
As someone who bought a RX580 for playing with Deep learning with ROCm (It was supported at the time). After posting to one or two bug threads, I had the same experience as the gp -- our issues were ignored. The issues have recently closed as the RX580 is no longer supported.
As for long term success, good luck, but once bitten twice shy.
It still won't. If you look at history we have been always shifting towards information storage that is easier and thus less energy intensive to copy.
Art by definition has done the opposite. Unique pieces that are HARD to copy (IIRC art only gains value once the artist is dead) and thus can gain value.
This feels to me like a weird version of DRM which has no real world use case.
LOL, just had exactly the same thought.
> And I'm no Rust developer, but it looks to me like it basically demonstrates how Rust is an abject failure in that regard. The developer has to jump through lots of nonobvious hoops and choose between competing libraries to get anything useful.
As a rust developer, there are other ways to skin a cat, or an Error return as it were. For the std::net library (I've been using it when dealing with tcp/udp sockets), when a socket returns an Error, it uses std::io::Error [1]. This is basically a struct that implements the display and Error traits, it stores an enum inside of the types of errors that you may want / need to ignore/ handle. You don't technically need to use libs to do anything error related.
This code has been round since Rust 1.0. Imho, this is kinda how Rust should tell people to make/handle errors. I like it. But I also have found rust enums to be extremely powerful in a lot of use cases.
[1] https://doc.rust-lang.org/std/io/struct.Error.html
You are say that the ReMarkable is open, but where is the GPLv2 code for the underlying Linux OS? As far as I can see there is nothing on the site that makes mention to it. That includes the Legal section which makes no mention of the GPL licensing.