Ah, so homegrown scum. I kind of lump them under the mega corporation header though as the goal for them is to eliminate regulations and oversight so they can pillage to their hearts content. Really trying to speed run that late stage capitalism dystopia.
Going to be real interesting to see where that money is coming from. My bet is some combination of the worst of the US political “thinktanks” like the federalist society, Russian assets, and mega corporations like Amazon.
Is it still passing the Turing test if you don’t think either one is human?
Yes and no. Even when refreshing rapidly the power draw is still significantly lower than something like an LCD, but not as low obviously as when refreshing slowly. It is nice to have the option of a high refresh rate if needed occasionally, but since every eink display I’ve seen with it to date suffers from absolutely horrendous ghosting when doing so the utility is highly questionable. Lets just say I am very skeptical of that claimed 30 Hz refresh rate and highly suspect it’s impractical marketing BS.
I’ve got an ereader with a color eink display with an identical PPI rating for color display. The fact they call out color PPI specifically gives a clue that this is the same tech which uses a color filter on top of a black and white eink display. In black and white mode it should be able to achieve about 300 PPI which provides a noticeably improved display. 150 PPI is a little chunky and at least for text ends up looking a little aliased and jagged.
The only somewhat impressive metric for this is the refresh rate of 30 hz, although that’s not really groundbreaking either even if it is a higher rating. What’s not mentioned and is very often an issue with those high refresh rates is they tend to both suffer from severe ghosting and reduced display lifespan.
The other major issue at least with all the existing color eink displays is that the colors are just not that impressive looking. Because of the filter they end up looking very muted, more on the pastel side of things rather than the bright vibrant colors we’re used to from traditional displays or even printers.
Microsoft’s requirements for Windows 11 include a 1GHz or faster CPU with at least two cores, 4GB of RAM, 64GB of storage,
All of this is no problem and essentially any computer manufactured in the last couple decades can meet these requirements. They’re effectively irrelevant for this discussion.
Secure Boot capability, and TPM 2.0 compatibility.
This is the problem right here. Pretty much every last computer you hear about that isn’t compatible it’s one or both of these, almost always the TPM 2.0 module.
That of course is if the reason you aren’t “upgrading” is because the hardware isn’t supported. For a great many of us our hardware is supported, we just don’t want all the bullshit anti-features Microsoft has crammed into Windows 11. Windows 10 was already bad enough with it’s constant telemetry spyware, that annoying Cortana garbage shoehorned in anywhere they could manage, the absolute atrocity that they turned the start menu search function into, and the annoying Teams and OneDrive integrations that randomly reinstalled and re-enabled themselves after updates.
Then MS went and had to cram in even more spyware by way of their horrible copilot garbage. All for what? What are we getting with 11 that’s better than 10? What feature justifies that upgrade? Nothing, that’s the answer. There’s no reason at all that 11 needed to be made.
Ah, I see the confusion. Originally you mentioned two Proton services, password manager and email provider. The person who replied to you suggested two alternative password managers (one commercial, the other one FOSS). You then replied saying without a specific email feature it would be pointless, which would be fair for an alternative email provider but doesn’t apply in this case.
What do you mean by email aliases?
Please see exhibit A, the US telecoms infrastructure which has backdoors added by the alphabet agencies and has now been so thoroughly violated by Chinese hackers that they’ve basically given up trying to fix it. It would literally be easier to burn every telecom installation in the US to the ground and build new ones on the ashes than it would be to remove all the Chinese rootkits and back doors. All because someone just had to have a backdoor for the NSA/CIA/FBI.
Because they need a constant stream of data to feed the models. If people had to opt in then they’d be less likely to do so and the models would starve and become less accurate and therefore less valuable to sell. Remember the trained model is the valuable piece of the entire thing, that’s what companies pay money to gain access to. There’s no point in sitting on all that user data if they can’t turn it into a marketable product by feeding it into a model.
I’m just annoyed that the term AI has been co-opted now to refer to pretty much any form of machine learning. Stuff gets called AI today that wouldn’t have been considered AI even 10 years ago. I think that’s part of what’s driving peoples ridiculous expectations because they hear AI and they expect actual AI not a glorified smart fill.
Try posting a picture of Winnie the Pooh and see what that gets you.
You’re being too literal with the term copyright. Fundamentally what copyright has always been about is preventing someone else using your work for their own gain without your permission. In that respect yes, copyright is critical in the digital age. The problem is that it’s a compromise. It balances the rights of someone who has “purchased” a copyrighted work with the rights of the creator.
Generally the balance that has been struck is that as a purchaser you have the right to do anything that you want with a work except to sell a duplicate of that work. You can sell the work, so long as you no longer retain a copy of it yourself. In practice this means transferring rather than copying. How exactly that’s accomplished gets into the weeds a bit if you start splitting hairs, but what’s important here is the spirit of the thing, nobody is going to care if technically you both have a copy for some short period of time in the middle of the transfer process.
As for “copy protection” aka DRM that is and always has been complete bullshit because it is a fundamentally intractable problem. There’s exactly one way to enforce copyright and that’s the legal system, anything else is doomed to failure.
We also desperately need to prevent companies from using that monopoly to prevent older works from being available by having the copyright and not publishing the work
This is solved by limiting copyright to a short duration after which the work enters the public domain. If a company wants to squander a copyright by sitting on it for the limited time they have it that’s fine but they’re only hurting themselves. The only reason this is an issue now is because of the ridiculous century long copyright terms we currently have. If copyright was reduced to a decade you would never see this happening anymore. That said a safeguard should also be in place to prevent copyright being used as a censorship weapon by the wealthy. I think a “use it or lose it” clause that immediately enters a work into the public domain if it’s not available for some period of time (maybe a couple years) would nip any potential issues there in the bud.
Copyright isn’t a stupid concept in the digital age, if anything it’s more important than ever but it is grossly out of control and needs to be severely curtailed (along with all other IP law). Copyright needs to go back to what it was originally intended as, a short term monopoly on a creative work. Something like 10 to 20 years. The current 100+ year copyright durations are absolutely ridiculous and never should have been allowed.
You absolutely should not be just ignoring too many requests responses. The entire point of putting rate limits on APIs is to reduce resource usage and while it doesn’t take many resources to serve up a request denied message that amount isn’t zero. If you continue to hammer an API that has rate limited you at some point they will decide your traffic is malicious and just start blackholing all your requests.
I’m honestly not sure what the best way to do rate limiting would be, I suspect that might depend on a number of factors such as what web client and async framework you’re using, but I would recommend if at all possible using a library rather than rolling your own. The library you found so far seems reasonable enough at least as a first attempt.
Well AMD just blatantly copied Nvidia’s naming scheme for their new GPUs so maybe they’ll copy Intel for their CPUs. I mean, they kind of already did, since the Ryzen 9 is basically i9, and the Ryzen 7 is basically i7 etc. It’s mostly AMDs mobile CPUs that have horrendous names, but Intel really isn’t much better in that department.
That was my plan until MS installed copilot on my system without asking. A month later I installed Linux and haven’t looked back. I did dual boot just in case I needed it, but I actually haven’t had to boot into windows for the last 4 months. It’s gone so well I’m currently planning to do the same to my wife’s computer in a few months when I give it its hardware refresh.
Reading the comments it seems like there may be a bunch of Rust jobs, they’re just not advertised as much and many of them are filled by senior people with expertise in other areas and languages. In particular it seems like a lot of jobs at Amazon in the AWS department use it heavily. It might simply be too new to really see heavy recruiting for new hires yet. In another decade as teams expand and senior people move to other positions or retire we might see a sudden surge in companies looking for Rust devs.
Cargo is doing too many things at once. It’s a build system but also a package manager but also manages dependencies? Idk what to even call it.
Somewhat agreed, but it’s a very difficult problem to solve. No language has yet come up with the perfect build tool. JS is on what, like the 12th build tool in as many years now? Some serious throwing stones in glass houses vibes here.
Syntax is very confusing for no reason. You can’t just look at rust code and immediately know what it does.
Strongly disagree on this point. Those extra glyphs in Rust are not just cosmetic, each one means something very specific and conveys very important information.
Having to pollute your code &, ? and .clone() everywhere to deal with ownership
You don’t “deal with” ownership, it’s an incredibly powerful tool you use. This just sounds like you haven’t really understood what the borrow checker is actually doing and the hundreds of problems it solves for you. I can not count how many times now I’ve been working in another language and had the thought “I could solve this with the borrow checker”
Js is way more readable.
JS is not more readable, JS is just far less detailed. It omits a vast swath of information such that you have almost no idea what it’s actually doing. It feels easier to you because you don’t care about any of the details, but those details become vitally important when things stop working and you’re trying to figure out why. This sounds to me like you’ve never had to write any actually complicated code. If all you’re trying to do is chain together a series of HTTP calls and maybe parse a tiny bit of JSON, yeah, Rust is like using a nuke to kill an ant.
Similarly, Async code starts to look really ugly and overengineered in rust.
A little bit, but mostly because doing async right is really complicated. Once again no language has a really great solution to this problem yet, they all involve tradeoffs.
Multiple string types like &str, String, str, instead of just one “str” function.
Once again it seems you don’t really understand the difference between owned and borrowed values or stack vs. heap allocation and why it matters. Really there’s only one type of String which is String, the others are just different ways of borrowing a String (with different tradeoffs).
i32 i64 i8 f8 f16 f32 instead of a single unified “number” type like in typescript. Even in C you can just write “int” and be done with it
If all you want is a “int” you can just use i64 for everything and “be done with it” as you say, you’ll just be adding a ton of wasted memory and needless overhead for no good reason. Seems like you just don’t like strong typing. I’m surprised you even bother with TypeScript instead of just using JavaScript.
Having to use #[tokio:main] to make the main function async (which should just be inbuilt functionality, btw tokio adds insane bloat to your program) yet you literally can’t write code without it.
You absolutely can write code without using #[tokio:main], you can even use tokio without that, it just saves you having to write a bunch of boilerplate to initialize tokios executer and pass your async functions to it. You can even use async functions without tokio, you just need to provide your own executor. Async in Rust is still pretty new and some of the rough edges are still being worked out, it will get smoother, but honestly the things you’re complaining about aren’t even the annoying parts about it.
Speaking of bloat, a basic get request in a low level language shouldn’t be 32mb, it’s around 16kb with C and libcurl, despite the C program being more lines of code. Why is it so bloated? This makes using rust for serious embedded systems unfeasible and C a much better option.
I have no idea what you’re doing to generate code sizes like that, but I guarantee you could get a significantly smaller program in Rust that does exactly what the C code is doing. As for embedded this is patently false. I personally use Rust regularly on embedded devices that don’t even have 32mb of RAM on them.
With cargo you literally have to compile everything instead of them shipping proper binaries. Why???
This isn’t a cargo thing, this is a Rust compiler thing. The Rust ABI hasn’t been standardized which means currently there’s no guarantee that Rust code compiled by one version of the compiler can successfully link against code compiled by a different version. Until not that long ago C++ actually had the same problem. This will eventually get fixed, but the language team feels things are still moving too fast to define a concrete standard yet.
Another major issue I’ve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked.
Rust is still pretty new, so a lot of libraries are still in active development, but there are already many excellent and very well documented libraries. Axum is literally one of the newest web frameworks in Rust and didn’t even exist that long ago. I’ve seen far worse documentation for JS libraries (and don’t even mention C, the gold standard there is practically a man page that’s just a glorified header file).
As for “memory safety”, it’s a buzzword. Just use a garbage collector.
Memory safety is not “just a buzzword”, there’s a reason all the top vulnerabilities for decades now are all memory safety issues. As for a garbage collector, good luck with that when writing embedded software or a kernel.
The rest of your rant basically boils down to “my particular simple use case doesn’t see much value from what Rust provides”, which is fine. If you don’t need the power of Rust, use something weaker, not every problem needs the nuclear option, sometimes you just need something quick and dirty that will run a few times before it falls over. Hell, sometimes a quick Perl script is the right solution. I mean, not often, but it does sometimes happen. When you do find a problem that your quick and dirty approach isn’t working on then you’ll see the value in Rust.
This is interesting in a “how far can you launch a pumpkin using an air canon” way, not a “you only need to cool this down to -40C to make it super conduct” way. It’s a fun experiment with nearly zero practical purpose outside of some very niche edge cases. Wearable computing is probably the only realistic one at the moment for a CPU that you can stretch a little and runs incredibly slow.