HN user
I did read it and it is honestly not that complicated. The SEC is being generous here. They could make the argument even if there were no validators. But I hope this is the start of them shutting down the validators too.
ETH is operating and trading with the US. It falls under US jurisdiction. The line of "we are not registered anywhere therefore we don't have to follow laws in any jurisdiction" is pretty weak and farcical. And sorry to be cheeky but... Have you seen some of the absurd claims and arguments crypto people make about the "infinite power" of crypto to somehow evade all laws and solve all social problems, while simultaneously making everyone rich just for holding some tokens? I wish I was making this up, or maybe I was just getting trolled...
How many people have committed such egregious crimes using blockchains that it is literally worse to spend your entire life in jail than it is to give up your Bitcoins? That scenario you've presented makes absolutely no sense to me.
But anyway, it's still entirely wrong because they can still just catch you using traditional means. Like catching you on tape admitting you stole the Bitcoins, or getting a video of you doing it, or getting credible witnesses to say that you did it. Or similarly, to retrieve the stolen coins just get a video of your keyboard while you type the pass phrase to the wallet, or just liquidate the rest of your assets into dollars and pay back the victim that way... Like the whole thing just makes no sense. Even if it did actually work it would still be terrible because the system you describe means that if you get your bitcoins stolen and you catch the thief and he admits he did it and then intentionally goes to jail to avoid having to give the tokens back so they just sit there unused in the wallet just to spite you... you can literally never get them back. Why would anyone actually want that??? I am honestly trying not to make this so outlandish but this is entirely what you just described. It's completely ridiculous.
The only thing this accomplishes is if you are trying to destroy money and make someone suffer by taking destructive actions... but like, if you are really an evil and petty criminal person you can also just do that with anything else? Like, rob them at gunpoint and set their cash on fire? Or slash their car tires? No one needs Bitcoins just to be an asshole, you can see that every day on this planet...
the right to examine products and discuss what you learn is really really important and is the basis of security research
I hate to push back on you (of all people) for this, but no it's actually not. You are talking too much with your hacker hat on and not enough with your legal hat on. There is quite a difference between accredited security firms doing responsible security research, and random unaffiliated parties with shifting and conflicting motivations doing "security research". That angle is a losing angle and it's not because these companies did anything, it's because it is actually a fallacious and bad meme that has propagated around forever in hacker circles, seemingly for no other reason than that it is fun to think about it.
In my opinion, if you follow that "right" to its legal and technical conclusion, you will end up with the "right" of corporate security firms to do research. That's it. I don't mean to be all doom and gloom though. You are right that the idea of "right to repair" is a much broader thing that makes a much more compelling case for any kind of consumer protection angle.
You can like something and still admit that it is awful. I "liked" C for a long time before there were better options...
If we are offering absolutist opinions, I would like to offer a counterpoint.
I've got macros to do automatic bounds checking. I've got RAII and stack traces. I've got structured concurrency, which will give the same capabilities as the Rust borrow checker if you adjust your coding style. And all this in portable C11.
You can do this all in C but it is an absolute nightmare. Every large C program grows some strange bespoke and incompatible versions of all that stuff at some point. And they're all a pain to use because none of it is idiomatic to the language. It's seriously awful. Things like the Linux kernel are the worst offenders. I will be happy when the C language finally reaches the end of its miserable, slow, agonizing death.
If you take that angle then crypto will still never be a legitimate investment class either way, because all of it (including BTC and ETH and everything else) is a giant fraud predicated on the falsehood that it is "decentralized" and somehow that makes it unregulated. There is no other reason for it to exist. This is just another nail in the coffin, they can't lie about it anymore.
If crypto-land really wants to follow through on their lawless anarchist fantasies, then they should be even happier if the SEC bans all of it outright. Then they can all go back to their roots when the only thing bitcoin was used for was illegal black market drug transactions...
GNOME is probably worst DE imaginable. After 20 years, they still don't have thumbnails in filepicker and even dropped preview side pane in GTK4.
Really disappointing to see this very lazy and trite criticism upvoted. If you look in KDE Plasma or Sway, you can also find plenty of missing features and bugs. You can find those anywhere.
You might also want to note that the fantasy of being able to use the same protocol to drive the local display and also operate over a network, is long dead. It seems like a clever idea but it doesn't actually work. It ceased to be a thing entirely the moment wide area networks became popular. The local and remote cases are two completely different situations that need their own individual attention. Even when developing against X11 protocol you still have to consider this in modern times because the DRI extension is not available over the network.
Compare to a protocol like RDP which is extremely optimized for efficient and secure network operation, but is also way more complicated as a result, and it would be foolish to use it on a local display server.
You can make all the arguments you want but it won't do anything meaningful. If those 1000x people expressing opinions have the necessary domain expertise, and aren't just tossing out their feelings on what they think might be cool or might be nice in a perfect world, then they should start contributing to these projects and fixing the bugs.
I mean, I think it would be cool if my PC never crashed. Isn't it easy and fun to say things like that?
and I'm not really interested in hearing that my own experience with it working well is a lie or some trick.
Your own experiences with it aren't a lie, but they're probably based around ignoring the last 20-30 years of advancements, and ignoring many actual statements from the X11 developers saying that it's bad for remoting.
Wayland gives up some things
Well in the case of X11 fowarding, no it doesn't. That still works.
Also, those of us who use non-mainstream window managers (such as Window Maker) are not interested in hearing that we should switch to some UI which doesn't support our workflow just because it's more fashionable these days.
By insisting on using these obscure, non-mainstream and under-maintained environments you are setting yourself up for an extraordinary amount of pain for very little benefit. The more time you spend avoiding the issue the harder it gets to figure out how to adapt your workflow to something else. I'm sure you understand that more deeply than anyone else here. So why keep up with the charade? It is not doing you any favors. At some point we have to let bad habits die.
But GNOME has zero reason to implement server side decorations in Wayland. All GNOME apps use client side decorations and have done so for years. The other major toolkits (Qt and Electron) have also added support for client side decorations. Legacy X apps are still able to use the X decorations. The only thing left is apps that were broken in Wayland in the first place.
Then can you explain what was biased about an admissions process that does not discriminate on the basis of race, gender, and other identity characteristics, if it wasn't the demographics of the student body? It's still vague how a race-agnostic admissions process would be biased.
There can still be implicit bias. Please read this publication from MIT on this exact subject: https://tll.mit.edu/teaching-resources/inclusive-classroom/i...
An African American student in the 4th decile (as in, is scoring above 40% of students and below 60% of students) has the same chances at admission at an Asian student in the top decile.
Ok, but that still doesn't change the facts. The issue is not that there aren't enough qualified students or that unqualified students are being placed above qualified ones or that merit is being ignored. That just isn't what's happening at all. That graph is missing a lot of important context, like the actual court case it was talking about that is currently headed for the Supreme Court:
https://en.wikipedia.org/wiki/Students_for_Fair_Admissions_v...
The whole thing about "we need more merit" is a misdirection. It's a bad, irrelevant take. This professor should be ashamed to have put his name on such dreck.
If I have 500 qualified white applicants and 5,000 qualified Asian applicants and I admit 100 whites and 100 Asians have I not discriminated against Asians?
It very well might be so, but now you're coming back around to the same thing about implicit bias again, the very thing that the original article was dismissing as not an issue. The plaintiff even argued in court that Harvard was doing this...
compare systemd's timers to cron implementations sharing crontab format, or systemd journal to syslog implementations, sharing its standardized protocols. With a single interface and different implementations, you can easily swap those, but with a monolith like systemd you are mostly stuck if the software actually makes use of it.
But this still makes no sense. You can just develop another thing that converts from the systemd format to something else, or make the other daemon capable of loading the systemd format directly. It isn't even hard to do this, I've seen various things do it. And depending on where you are the systemd formats are arguably more standardized than old crons and sysloggers in the current year.
They are less common than HTTP stacks.
libsystemd includes a d-bus library for exactly this reason.
That's not really relevant. You can personally choose to not use Electron apps, but many people cannot or do not want to choose to do that. Like it or not, it's a thing now. I've noticed a lot of developers seem to have this confusion that anyone else can avoid Electron. I guess you can if you spend all day in the terminal and the IDE but most other people cannot.
And that sounds like something is seriously wrong with your machine or your drivers. GPU rendering has massively improved performance and battery life on every machine I've ever tried. And especially on embedded devices with a low power mobile GPU, see for example here: https://social.librem.one/@dos/104984930233748319
Compositing should do so as well by avoiding unnecessary redraws. That sequencer would probably benefit greatly on a Raspberry by using GPU rendering, the screenshot even shows it rendering video and shaders...
That is a correct conclusion, in the same way that many issues with X features are not actually issues with the X server. Over the years a lot of things have been moved out of the X server into client libraries, or into Mesa, or into D-Bus, or into Wayland...
That's not a good comparison because it would be even harder to write your own X server. And yet X is still extremely fragmented.
And developing a new compositor also does not require wlroots. Originally there was libweston, wlroots is just another option.
This is a result of them learning lessons from X history. The lesson from X is that mouse configuration absolutely does not belong in the display protocol and should not require futzing around with editing a root-owned xorg.conf. Input configuration is an entirely separate concern.
You're being vague here, but I suspect by "biased results" you mean they produced a racial (and perhaps gender) makeup you don't like.
No, you are completely and utterly wrong on that. This is more of the same intellectually lazy assumptions, please stop this.
And I get his point perfectly, it is still insulting and dismissive. When someone starts talking about school vouchers and "merit" in the context of this then it's mostly an admission that they don't know what they're talking about. It has absolutely nothing to do with the problems faced by a school like MIT that already has an extremely low acceptance rate anyway. They know how to test students on academic rigor, that isn't the issue. The fact is, they already cannot accepts all students who pass based on academic merit alone. Your chart even demonstrates that is the case with Harvard, the issue is explicitly not that racial makeup is being considered over academic achievement.
No, it is not the opposite. That suggestion is just restating the question. They already tried to build a system that uses merit and qualifications alone, and the complaint is how doing that has led to extremely biased results.
There is nothing wrong with disagreeing on how the decision is made, but the piece itself is poorly written, intentionally inflammatory, and insulting. There are maybe two valid suggestions buried within a bunch of nonsense, which shouldn't be the case for such a short article. It always disturbs me how anyone is willing to publish these terrible, low quality op-eds. And then when people get angry at them for their writings being low-quality, insulting and inflammatory, they have the nerve to complain that people don't want to hear the rest of their opinions... Instead of, you know, addressing the issue that caused the anger and changing the bad opinions accordingly.
If by "the DEI people" you mean "students who were only able to be there because someone made a conscious effort to do diversity outreach" then yes. They would be opposed to someone suggesting that they should stop the outreach so that people like them could no longer be there.
His piece (you can read it here: https://www.newsweek.com/diversity-problem-campus-opinion-16...) is more of the same intellectually dismissive rhetoric that we've seen a thousand times before. As usual it's got all the same nonsensical discriminatory suggestions that don't actually help people, like "support charter schools" and "we should use a process based on merit and qualifications alone" and "we should build a system that uses merit and qualifications alone but is also unbiased". And just for fun he suggests at the end that any university even considering how to approach race issues is somehow comparable to nazism. This is just bad writing, I don't blame the students for being upset. Have you noticed how very few students who are actually underprivileged would ever share these views?
Lightning network and other Layer 2 solutions are a joke. Those are only created because the Bitcoin network was intentionally designed to be slow and congested, to make it artificially expensive, and waste ridiculous amounts of electricity in the process. If those things actually worked then someone could make them work with anything else as a settlement layer, even traditional currencies. There is no actual reason for them to use Bitcoin.
Most of your comment is pretty bad misinformation. X11 was not designed to use Xrender. That was an optional extension that came later. And on many drivers, the drawing of XRender is still not actually GPU accelerated either. Remember that XRender was designed long before GPU drivers were in the state they are now, back in the era when people still thought 2D acceleration was going to be a thing. And, XRender is extremely limited to a small handful of primitives that were mainly used to implement the postscript drawing model used by cairo.
It is also not trivial to reduce the amount of roundtrips in an X11 program. If the program uses Xlib then it probably needs to have significant portions of it rewritten to use xcb, which is a lot more complicated than it seems because Xlib handles a lot of caching and logic that xcb simply does not. In some situations X11 roundtrips are simply unavoidable. Complaining about GTK or Qt will not change this. Even if it were possible to fix those, there are less and less contributors to those projects who are willing to spend time to maintain X11 support.
Sorry, I didn't clarify. The bug was fixed with some use of pixmaps, in other situations it's still broken.
It sounds like the vast majority of apps you use are very old. Even plain productivity apps benefit from GPU rendering. If they don't it's because those apps are far behind, compare to things like Electron apps where everything has been GPU accelerated for quite some time because of Skia.
That flag has been broken for years: https://bugreports.qt.io/browse/QTBUG-70387
I doubt it will ever be fixed, because it offers no benefits when the application itself uses actual hardware rendering with GL or Vulkan. XCB can't speed that up at all.
You can still do that with systemd though. If you want to swap out some components then just don't use those features in your unit file, instead have your unit file run a shell script that uses your components. The "opposition" to systemd has never made any sense to me on any level.
GNOME just refused to adopt it
No idea where you heard that information but it is extremely incorrect. See here:
https://www.phoronix.com/news/GNOME-Mutter-Mainline-EGLStrea...