Am I misled in thinking that if this weren't mere IP trolling with no legal or even factual basis, SFC would've already thought to sue the biggest fish, i.e. Amazon, as they aren't publishing full Linux kernel sources as used in Kindles inside the "source releases", most notably the REAGL part of the EPDC driver…
A common strategy is to first establish precedent by successfully suing smaller / less deep-pocketed entities, and then using that victory to compel more resourced organizations to comply. When SFC brought this lawsuit, Vizio was an independent company and much smaller than Amazon. Of course, its purchase by Walmart in 2024 changes that a bit—but before then, easier for SFC to face Vizio’s legal team than Amazon’s.
Yeah, it would be so much better if it was American-made, because as everyone knows there are no corrupt people in the US and every person of Russian descent is a spy for their motherland's government (:
Yes, it would be better if it was American made, because the US government has lesser capability to compell otherwise independent developers to do their bidding.
> US government has lesser capability to compell otherwise independent developers to do their bidding.
Are you sure about this? The US, like most countries with extensive intelligence capabilities, does not have a good track record of convincing their citizens of doing shady things [1].
You missed my point, which is that all governments exist to oppress by design, it's literally what governments are, they are businesses that monopolize violence. Some people, esp. people of the Western world are too arrogant to admit it. Personally, I would honestly rather trust someone who is aware of that fact over someone who isn't.
Look, I'm as much an enjoyer of Kropotkin and von Mises as the other guy and torched more then zero regional police HQs in my life.
You are right in principle, but there is a varying degree to which different governments actually oppress people and there are certain patterns of what to expect from which.
I would not trust american company, like msft to not snitch to me to US government either, but the likehood of random shmuk being coopted is much more likely in one case as opposed to another.
> the likehood of random shmuk being coopted is much more likely in one case as opposed to another.
I don't think Russians actually live in fear of the big brother, I wouldn't be friends with so many Russian femboys if that really was the case. But what do I know, it could all be a conspiracy.
Edit: I also don't understand how torching police hqs makes the world a better, more peaceful place. At best, you'll just end up creating another monopoly on violence… @.@
I've never read proprioception described as a sense of balance before. AFAIU, proprioception is the sense of where your body parts are in relation to each other--arms, legs, head, eyes (and eye gaze), and much more that's difficult to enumerate or describe. I guess that's critical to maintaining balance, but not sufficient? Summarizing proprioception as balance seems wrong even if the inner ear vestibular system (which is where our "sense" of balance is regulated, AFAIU) is a component of proprioception.
And in addition to proprioception, we can sense hunger, thirst, tiredness, time, temperature, balance, our own movements, pain, pressure, and maybe even itching. It's just that "we have discovered a seventeenth sense" has less glamour to it
Mhm, this is a proprietary OS developed by a dilapidated company… Here is another OS sharing the Nokia/MeeGo heritage, except fully open source and actively developed (not ready for general use either, AFAICT [yet]): https://nemomobile.net/
The ID presented at time of purchase does not have to be the ID of the actual user of the card. Your local drunkard will be happy to get $10 to buy a SIM card for you. Or you could visit eBay (or local equivalent) and get a valid SIM card without leaving your house.
"For the Selfie-Ident you identify yourself with your identity card, passport or residence permit. (Selfie-Ident is currently possible worldwide with the German ID card, residence permit and passport. Alternatively, you can use Video-Ident and identify yourself in a video call with an employee.)
Important: Temporary identification documents are not supported due to internal check. You need a tablet or smartphone with a camera and an internet connection."
In my country, giving a SIM card to another person who does something illegal, is a crime. No doubt EU might soon have the same law - they are pretty good at copying.
As a result, sites where I could rent a number for verification, now don't offer local numbers anymore.
Even with fair usage policy violations (like long term roaming) the prices are still quite reasonable: 1.30 EUR/GiB (+VAT); from next year 1.10 EUR/GiB (+VAT).
The only thing that happens is your data becomes a lot more expensive, the card still continues to work as normal. I've not lived in Poland for over 15 years now, and I still have a polish SIM card that I use almost daily - the only thing that I've lost due to roaming long term is cheap data packs, I can still call and text as normal from my monthly allowance.
There's eu(maybe even EEA?) wide free roaming legally mandated since I think 2017 or so? But it's not a permanent solution, your second paragraph still holds true.
As far as I know it is only EU. Both UK and Switzerland have some operators that roam and some that do not. fwiw, fastweb in Italy provides roaming in both and has a very generous fair usage policy.
That's because we are no longer in the EU. Before Brexit they were legally mandated to allow free roaming in the EU. Now they are back to charging whatever outrageous prices they wish.
Now I wonder, what could "cleverness-shaped ears" possibly look like? Also funny: my ears can't hold earphones, they just eject them every time I change my facial expression or talk or what-not.
Rustlang doesn't aim to address race conditions. Sounds to me like overly "cautious" inefficient code you can write in any language. Think using `std::shared_ptr` for everything in C++, perchance…?
The comment probably refers to data races over memory access, which are prevented by usage of `Send` and `Sync` traits, rather than more general race conditions.
I see, but that's not the point of my comment. I don't know rustlang, perhaps I could address that if someone translated the rust-specific parlance to more generally accepted terms.
I'm not sure I understand the point of your comment at all.
Rust does, successfully, guarantee the lack of data races. It also guarantees the lack of memory-unsafety resulting from race conditions in general (which to be fair largely just means "it guarantees a lack of data races", though it does also include things like "race conditions won't result in a use after free or an out of bounds memory access").
If by address it you mean "show how C/C++ does this"... they don't and this is well known.
If by address it you mean "prove that rust doesn't do what it says it does"... as that point you're inviting someone to teach you the details of how rust works down to the nitty gritty in an HN comment. You'd be much better off finding and reading the relevant materials on the internet than someones off hand attempt at recreating them on HN.
The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance.
Sadly, I don't know rustlang, so I can't tell if the inability to describe its features in more commonly used terms is due to incompetence or the features being irrelevant to this discussion (see the title of the thread).
The thing is you aren't really asking about a "feature" of rust (as the word is used in the title of the thread), unless that feature is "the absence of data races" or "memory safety" which I think are both well defined terms† and which rust has. Rather you're asking how those features were implemented, and the answer is through a coherent design across all the different features of rust that maintains the properties.
As near as I can tell to give you the answer you're looking for I'd have to explain the majority of rust to you. How traits work, and auto traits, and unsafe trait impls, and ownership, and the borrow checker, and for it to make sense as a practical thing interior mutability, and then I could point you at the standard library concepts of Send and Sync which someone mentioned above and they would actually make sense, and then I could give some examples of how everything comes together to enable memory safe, efficient, and ergonomic, threading primitives.
But this would no longer be a discussion about a rust language feature, but a tutorial on rust in general. Because to properly understand how the primitives that allow rust to build safe abstractions work, you need to understand most of rust.
Send and Sync (mentioned up thread) while being useful search terms, are some of the last things in a reasonable rust curriculum, not the first. I could quickly explain them to someone who already knew rust, and hadn't used them (or threads) at all, because they're simple once you have the foundation of "how the rest of rust works". Skipping the foundation doesn't make sense.
† "Memory safety" was admittedly possibly popularized by rust, but is equivalent to "the absence of undefined behaviour" which should be understandable to any C programmer.
> The point of my comment is that in my experience, incompetently written, overly-cautious code tends to be more safe at the expense of maintainability and/or performance
Well, yes, but that's the whole value of Rust: you don't need to use these overly-cautious defensive constructs, (at least not to prevent data races), because the language prevents them for you automatically.
Safe Rust does. To the extend Rust interfaces that wrap kernel APIs will achieve safety for the drivers that make use of them remains to be seen. I think it will indeed do this to some degree, but I have some doubts whether the effort and overhead is worth it. IMHO all these resources would better be invested elsewhere.
Thats kinda the problem, there are concepts in rust that don't have equivalents in other common languages. In this case, rust's type system models data-race-safety: it prevents data races at compile time in a way unlike what you can do in c or c++. It will prevent getting mutable access (with a compile time error) to a value across threads unless that access is syncronized (atomics, locks, etc)
And from what I can see, rustlang mutability is also a type system construct? I.e. it assumes that all other code is Rust for the purpose of those checks?
> rustlang mutability is also a type system construct?
Yes
> I.e. it assumes that all other code is Rust for the purpose of those checks?
Not exactly, it merely assumes that you upheld the documented invariants when you wrote code to call/be-called-from other languages. For example that if I have a `extern "C" fn foo(x: &mut i32)` that
- x points to a properly aligned properly allocated i32 (not to null, not to the middle of un-unallocated page somewhere)
- The only way that memory will be accessed for the duration of the call to `foo` is via `x`. Which is to say that other parts of the system won't be writing to `x` or making assumptions about what value is stored in its memory until the function call returns (rust is, in principle, permitted to store some temporary value in `x`s memory even if the code never touches x beyond being passed it. So long as when `foo` returns the memory contains what it is supposed to). Note that this implies that a pointer to the same memory isn't also being passed to rust some other way (e.g. through a static which doesn't have a locked lock around it)
- foo will be called via the standard "C" calling convention (on x86_64 linux this for instance means that the stack pointer must be 2-byte aligned. Which is the type of constraint that is very easy to violate from assembly and next to impossible to violate from C code).
That it's up to the programmer to verify the invariants is why FFI code is considered "unsafe" in rust - programmer error can result in unsoundness. But if you, the programmer, are confident you have upheld the invariants you still get the guarantees about the broader system.
Rust is generally all about local reasoning. It doesn't actually care very much what the rest of the system is, so long as it called us following the agreed upon contract. It just has a much more explicit definition of what that contract is then C.
Also we can (in 2024 Edition) say we're vouching for an FFI function as safe to call, avoiding the need for a thin safe Rust wrapper which just passes through. We do still need the unsafe keyword to introduce the FFI function name, but by marking it safe all the actual callers don't care it wasn't written in Rust.
This is fairly narrow, often C functions for example aren't actually safe, for example they take a pointer and it must be valid, that's not inherently safe, or they have requirements about the relative values of parameters or the state of the wider system which can't be checked by the Rust, again unsafe. But there are cases where this affordance is a nice improvement.
Also "safe" and "unsafe" have very specific meanings, not the more widely used meanings. It's not inherently dangerous to call unsafe code that is well written, it's really more a statement about who is taking responsibility for the behavior, the writer or the compiler.
I like the term "checked" and "unchecked" better but not enough to actually lobby to change them, and as a term of art they're fine.
Yes. Just like C++ "const" is a type system construct that assumes all other code is C++ (or at least cooperates with the C++ code by not going around changing random bytes).
As far as I can tell, ANY guarantee provided by ANY language is "just a language construct" that fails if we assume there is other code executing which is ill-behaved.
a data race is specific kind of race condition; it's not rust parlance, but that specificity comes up a lot in rust discussions because that's part of the value
> since Rust is not the only language susceptible to data races.
The point is rather that it’s not. The “trait send sync things” specify whether a value of the type is allowed to be respectively move or borrowed across thread boundaries.
I mean, reliably tracking ownership and therefore knowing that e.g. an aliased write must complete before a read is surely helpful?
It won't prevent all races, but it might help avoid mistakes in a few of em. And concurrency is such a pain; any such machine-checked guarantees are probably nice to have to those dealing with em - caveat being that I'm not such a person.
Heh. This is such a C++ thing to say: “I want to do the right thing, but then my code is slow.” I know, I used to write video games in C++. So I feel your pain.
I can only tell you: open your mind. Is Rust just a fad? The latest cool new shiny, espoused only by amateurs who don’t have a real job? Or is it something radically different? Go dig into Rust. Compile it down to assembly and see what it generates. Get frustrated by the borrow checker rules until you have the epiphany. Write some unsafe code and learn what “unsafe” really means. Form your own opinion.
reply