311–320 of 365 posts
Earlier quoted context omitted.
Can you give an example of a non-copyleft open source product where the major improvement is proprietary?
BSD -> Mac OS?
Earlier quoted context omitted.
I would be happily using HP-UX, Solaris and Aix to this day, so don't mistake my philosophical questions as a GPL advocate, just don't be surprised how the IT landscape will look like when GCC and Linux are no longer around.
Do you think there will be a possibility someday Linux will be replaced, both on Mobile ( Android ) and on Server? I keep wondering if Microsoft opens up the Windows Kernel ( And Kernel only ), would it change the landscape much.
On Android Linux is an implementation detail, most of it isn't exposed to userspace, not even on the NDK as Linux APIs aren't part of the stable interface specification.
And ART is being ported to run on top of Fuchsia as well (https://android-review.googlesource.com/q/fuchsia), so...
Earlier quoted context omitted.
Why do i want a PS4 specific cpu-drm feature in a generic Compiler?
I did not said it was a cpu-drm feature, rather optimizations that could reveal hints about it. I don't know, maybe other AMD users would like to get them?
>might provide clues how to bipass PS 4 security
>AMD users would like to get them
They got em:
https://www.phoronix.com/scan.php?page=news_item&px=Sony-Tha...
https://www.phoronix.com/scan.php?page=news_item&px=LLVM-10-...
https://www.phoronix.com/scan.php?page=news_item&px=Sony-LLV...
Why do i want ANY PS4 specific security feautures in the Compiler??
If we get the Rust backend for gcc finalized and merged first, it would be much easier to get Rust code into the kernel: > https://github.com/philberty/gccrs/
Earlier quoted context omitted.
They do, Sony also upstreams more stuff from their Android phones into AOSP than PS4 OS into FreeBSD, guess why.
>They do ?? What? >guess why Because protecting your games is kind of important for a Gaming-Console. Your answered your own question: >No, something like the PS4 CPU features that don't get upstreamed because they might provide clues how to bipass PS 4 security.
Earlier quoted context omitted.
>They do ?? What? >guess why Because protecting your games is kind of important for a Gaming-Console. Your answered your own question: >No, something like the PS4 CPU features that don't get upstreamed because they might provide clues how to bipass PS 4 security.
Right, I will have so much fun when millennials rediscover shareware and PD.
Earlier quoted context omitted.
Meaning, internal things in chromium change so fast, so you'd slightly wish you could have your custom changes merged into upstream? (I.e into chromium) So that the ppl at Google would keep your code working? And you didn't need to spend time resolving git merge conflicts, and compilation errors? But you cannot, because some of those bespoke changes are "secret" and what you make money from? (And maybe some changes a…
Yes. Also, the fact that Chromium is a high profile security critical software with occasional emergency security updates for bugs exploited in the wild, doesn't help at all when you want to maintain your own fork.
Earlier quoted context omitted.
> "In the wild" one hardly ever has to write unsafe Rust data structures and algorithms. one has to do it all the time if cyclic mutable graphs or specific buffers/caches are involved. > Verifying the remaining code is desirable but not as valuable as what Rust already provides. How do we know that? What are the criteria and the thresholds that lead us to that conclusion? Is it true for all fields where the language…
I can have cyclic graphs with mutable data without writing any unsafe code: https://docs.rs/petgraph/0.5.1/petgraph/ "Specific buffers/caches" is ambiguous. For embedded systems there are crates that provide safe interfaces to memory-mapped hardware. You will likely argue that using unsafe code in a library is just as bad as writing unsafe code, even if that library is used and tested by a lot of people and the unsaf…
You can, because the libraries that you use fallback to unsafe blocks. How about those who want to write these libraries without having to use unsafe?
> You will likely argue that using unsafe code in a library is just as bad as writing unsafe code, even if that library is used and tested by a lot of people and the unsafety is corralled behind a safe API. You would be wrong.
just because you think I'd be wrong doesn't prove me being wrong. Why should I rely on unsafe if I can implement the same algorithms and data structures with proper safety guarantees, but not in Rust? Why should I stick to Rust specifically for that matter?
> My current project is 170K lines of Rust code, and has 225 uses of unsafe. That's about 1.3 uses of 'unsafe' per 1000 lines of code. If I could write C++ code and introduce less than 2 exploitable vulnerabilities per 1000 lines of code I'd have an even higher opinion of myself than I already do.
yeah, it shows your personal commitment to Rust toolchain. This is good. But what if you've already acquired some knowledge of more powerful tooling out there, and you're given a task to estimate applicability of these two toolchains to the development of Linux Kernel?
> We should adopt proof systems that let us verify safety properties for those little bits of unsafe Rust code. We should not, however, make that a precondition for writing that vast majority of code that can be written in safe Rust in safe Rust.
Why shouldn't we do it specifically for Linux Kernel? Why shouldn't we use compile-time checks for element incusion, length-based non-emptiness of containers instead of implementing another set of runtime validators?
> Safe Rust is a sweet spot where the compiler and tools can verify a strong set of safety properties without the developer having to deal with proof systems and dependent types
How do you define a sweet spot? Is it indeed a sweet spot when it comes to kernel development? Why does this spot happen to be at the level of Rust type system, and not somewhere else?
> Trying to put the brakes on Rust and get everyone to buy into ATS instead is putting the needs of the few over the needs of the many.
I'm actually arguing here from a position of technical merit of two tools in the context of Linux Kernel development, but for some reason you bring vague and non-technical definitions of "sweet spot", "lots of people using something", "needs of the few vs needs of many", which I've not mentioned anywhere in the thread.
Earlier quoted context omitted.
Yes. Developing a state of the art optimizing compiler is hard . If their only choices are developing their own compiler or basing off of gcc and releasing their work, they'd choose gcc.
> If their only choices are developing their own compiler or basing off of gcc and releasing their work, they'd choose gcc. But that's the exact choice Apple faced in 2005 and they did not choose gcc . They paid Chris Lattner and his team to develop an alternative compiler. Excerpt from wikipedia[1]: >"Finally, GCC is licensed under the terms of GNU General Public License (GPL) version 3, which requires developers wh…
Earlier quoted context omitted.
My comment was entirely based on the second link. Direct quote from that: > Linux kernel forcing adaption of DRM, including HDCP. (Which linked to a patch adding driver support for handling HDCP, with absolutely no possibility of it somehow being forced.) Regarding the quote from that interview: sure, and there's also no guarantee that the Linux kernel won't drop support for every architecture except SPARC, except of…
I don’t know about Linux, but Mozilla has mandated many things that I would have hoped it never would have, like XUL depreciation, and especially added many anti-features to their largest product, deciding each was not their hill to die on https://news.ycombinator.com/item?id=24124954 . I left Firefox and have never regretted it. The Hyperbola devs did the same, and I will be happy to try their OS and support them fi…
Mozilla markets Firefox as ‘the only browser made for people, not profit’. But they’ve done the exact opposite time and time again. Virtually the single most prominent UI element, the omnibar, has been sold out to the single largest threat to the open web, the gatekeeper to the entire internet to the vast majority of its users. I don’t want to spend all day railing against Mozilla, as easily as I could, but I can easily find a couple other examples off the top of my head. The Mr. Robot scandal is another example of selling out and (not necessarily directly harming but very significantly) alienating users. And it’s been a few years since I’ve used FF as my main browser but I still remember every time I installed it on a new device going into settings and changing default after default to revert it back from a profit-seeking product to a personal tool, disabling telemetry, etc.
1: Although it does make a difference to me. I’d use pre-Chromium Edge if it was FLOSS, on my OS, and let me use Pentadactyl. The excuses for XUL’s removal — security, stability, and speed — don’t concern me: https://yoric.github.io/post/why-did-mozilla-remove-xul-addo... seems to claim it would allow someone to somehow steal my passwords. I’ve been using Palemoon for years and I don’t have any weird activity on any of my accounts, and I keep my browser sandboxed (something Firefox should do better by default, one way it’s behind Chromium) so I don’t have any other security worries. I have no stability or speed issues, and maintainability seems like a non-issue given that an apparently one-man main team keeps Palemoon running.