Amazing change, fighting with the back button is my least favorite part of the ad web and a blindspot for ublock. I wonder how Google is going to track this and if SPA style react router sites would be downranked because of the custom back button behavior. I doubt it due to their popularity but I'm curious how they're going to determine what qualifies as spam
Disregarding the fact that Bryan operates oxide a company that has multiple investors and customers (id say this proves valuable knowledge) the crazier fact is that people think html is useless knowledge.
React USES html. Understanding html is core to understanding react. React does not in anyway devalue html in the same way that driving automatic devalues driving manual
Go to Facebook.com and right click view source and tell me html is not being devalued. No person who wants to write aesthetic html would write that stuff.
When it matters it matters. Even in facebooks case they made react fit for their use case. You think the react devs didn’t understand html? Do you think quality frontends can be written without any understanding of html?
Like the article says we’ve moved an abstraction up. That does not make the html knowledge useless
Tbh this is like looking at any binary's assembly code and complaining it's "unasthetic".
Whatever blob of HTML the browser is offered is just the end result of multiple "compilation" steps. Nobody has spent a single iota of time thinking about whether it's pretty.
Just like opening any binary produces inelegant assembler.
A fat std lib will definitely not solve the problem. I am a proponent of the rust foundation taking packages under their wing and having them audited and funded while keeping original maintainers in tact
> fat std lib will definitely not solve the problem
fully agree, that was tried and failed severely
- in python there is a saying that standard library is where packages go to die. It's pretty common to pull in 3rd party libraries for things in python due to the build in version by itself sucks. Weather it's for UX, performance, bug-proneness, feature completeness and even "bad security choices stuck with for backward compatibility reasons" cases happened.
- in Java "batteries included" had been repeatedly involved in pretty bad security vulnerabilities. Often on the line of "that niche feature people may not even be aware of was callable though some reflection/dynamic resolution leading to a RCE".
In the end IMHO it's not supper relevant if the rust foundation takes packages under their wing or not. What matters is to create verifiable supply trust.
That crates.io is only meant to contain source code already helps, and them only allowing uploading new packages and yanking but not overwriting them also helps.
Go is another example of a fat std lib causing issues specifics with their crypto code.
I think in general the things people are worried about are
1. Maintainer quits
2. Bad actor becomes new maintainer
3. Bad pr
4. Account compromise
When I say I want the rust foundation to take them under their wing what I really mean is I want the foundation to provide funding and have packages undergo the same procedure as the main language.
If there’s a cve the foundation should orchestrate reporting and standardize it.
If it becomes abandoned the foundation should handle that.
Basically I want it to be an extension of the standard but not in a way that actually requires it to be so. I just want these packages to have the seal of approval of the foundation so I know that they have a minimum amount of quality and are vetted on the regular by a trusted entity
> If there’s a CVE the foundation should orchestrate reporting and standardize it.
to some degree that is the case.
There is rustsec CVE numbering agency, and crates.io on their website list CVEs reported to it under the `Security` tab.
In combination with cargo-audit, cargo-deny and co this is already quite useful. But IMHO as of now things don't yet fully "click together"/"work out of the box" and many IMHO needed parts are still missing.
I've said it before and I'll say it again. I'm glad rust has good package management I really am. However given that aspect, it ends up forming a dependency heavy culture. In situations like this it's hard to use dependencies due to the amount of transitive dependencies some items pull in. I really which this would change. Of course this is a social problem so I don't expect a good answer to come of this....
Definitely concerned to hear but I’m hopeful that the core of nasa is intact. They’re some of the kindest and smartest people I’ve had the pleasure of meeting. They don’t joke around with lives on the line. I hope the best for everyone involved. I’ll be watching the launch of Artemis 2 and 3 with excitement and hope.
They don't? They sure seemed to back when they ignored the engineers and launched Challenger, and again with Columbia. And those were times when the country had competent political leadership instead of a complete clown-show.
I have very, very little faith in NASA at this point after seeing how much the administration has wrecked other federal agencies like the CDC and NHS. There's no way I'd fly on that thing.
Not to beat a dead horse but I see this again and again with dependencies. Each time I get more worried that the same will happen with rust. I understand the fat std library approach won’t work but I really still want a good solution where I can trust packages to be safe and high quality.
Linux distros and BSD ports did that since the 90's. When Linux distros had barely a PM or just tarballs, Infomagic sold 4 CD full of libre software. When I had no internet at home, back in the day I bought 3 DVD's of Debian Sarge for 20 euros, about $20. A bargain, it was the price of a hard-cover best seller book.
GB's of libre software, graphical install, 2.6 kernel, KDE3 desktop, very light on my Athlon 2000 with 256MB of RAM. It was incredible compared to what you got with Windows XP and 120 Euro per seat. Nonfree software and almost empty.
And, well, if for instance I could get read only, ~16TB durable USB drive with tons of Guix packages offline (in a two yearly basis with stable releases) for $200 I would buy them in the spot.
You would say that $200 for a distro it's expensive, but for what it provides, if you are only interested in libre gaming and tools, they amount you save can be huge. I've seen people spend $400 in Steam games because of the Holyday sales...
Why wouldn't the "fat std" thing work? Yes it's hard to design properly, both in scope and actual design (especially for an unstandardized language still moving fast), but throwing the towel and punting the problem to the "free market" of uncurated public repos is even worse.
It's what we call in France "la fête du slip".
PS: that's one reason I try to use git submodules in my Common Lisp projects instead of QuickLisp, because I really see the size of my deptree this way.
Not necessarily, but let's agree that some design faults would happen: you still get the option to use the solid, boring and slightly rusty std instead of another 100 dependencies from the supply chain supermarket.
At work, we're happy with Python's included batteries when we need to make scripts instead of large programs.
NPM should have a curation mechanism, via staff review or crowdsourcing, where versions of popular packages are promoted to a stable set, like linux distros do. I would only use curated versions if they had such a thing.
- copy the dependencies' tests into your own tests
- copy the code in to your codebase as a library using the same review process you would for code from your own team
- treat updates to the library in the same way you would for updates to your own code
Apparently, this extra work will now not be a problem, because we have AI making us 10x more efficient. To be honest, even without AI, we should've been doing this from the start, even if I understand why we haven't. The excuses are starting to wear thin though.
As you should. Also, the constant complaint from devs on these very boards is that quality and security are relegated behind new features that are often described as useless but pushed by management.
I don't know where you've worked but a hostile and intelligent actor or internal red team would succeed under each of those cases at every job I've worked at.
Defending against a targeted attack is difficult, yes. But these recent campaigns were all directed at everyone. Auditing and inspecting your dependencies does absolutely help thwart that because there will always be people who don't.
They succeeded in poisoning the whole supply chain and making everyone distrust package management to a degree never seen before, and people who aren't reviewing their dependencies are already getting hit. You seem to suggest that we all accept that.
That attitude might be the reason why the places you've worked would be under threat. The places I've worked would also be under threat, because several of my colleagues had that attitude, and this is why red teaming works.
Absolutely ridiculous law. I pray to God the US does not follow. That being said there is some strange law trickery where passwords and pins are safe but biomentrics aren't. We should just standardize it in the US.
The US has been doing that for years already. There's plenty of stories of people (US citizens included) being detained by border agents in US airports for refusal to provide said agents with access to their devices.
They can detain you and take your device, but they cannot compel you to give up your password, to be clear. As a US Citizen you have a right to re-enter the country.
The letter of the law says you are correct. Reality however disagrees. People who are most definitely US citizens have in fact been put in jail for the simple not-crime of refusing to provide passwords to their devices to law enforcement.
reply