What don't you like about the new layout? I find it to be a really well-done change that helps to modernize the page without getting rid of its classic text-first approach. In fact, other than moving the table of contents to the side, I really don't see any major differences.
Also, if you don't like the new layout, you can get the old one back. If you create an account, and go to preferences -> appearance, you can change back to the old "Vector Legacy (2010)" layout [1]
Go Map!! can do everything, as mentioned by kevingrahl in a comment, but https://every-door.app/ is also very cool and very useful for small, quick edits of POIs.
As far as using OSM - I highly recommend Organic Maps, it doesn't offer editing features but It's great to use, the maps are all downloadable for 100% offline use and open source. It was made by the devs behind the original maps dot me (before it changed hands).
Rust is particularly strong because the crate system lets them slowly bring things into the stdlib.
There are many UI libraries for Rust; I’ve tried most of them, and all of them are radically different in their approaches. None of them are anywhere near as good as most UI frameworks in other languages (in my opinion).
Bringing a UI framework into the stdlib at this point in time would be terrible because the community still hasn’t figured out the best way to write a UI framework and it would stifle innovation in this developing section of the language.
I don't understand this website and why it always get linked. It's just a list of a bunch of crates unsorted. Most of them are unmaintained, or just early prototypes.
There isn't a good comparison of all these crates
It made sense to me - an Uninterruptible Power Supply should be sized according to the power draw of a computer. If these were power hungry CPUs, you would need a really beefy UPS. So that's what I thought they were trying to say!
It has taken huge amounts of work to get the Rust ecosystem to where it is. Even still, it has huge regions where it is immature. Is anyone in the D community able to talk about how mature the ecosystem is?
I had always assumed (perhaps naively) that not many people used D and that it was a bit esoteric…? Not to offend anyone. Kind of like F.
Should developers be investing time into learning D?
D has been around for 21 years. It has had a compiler in the gcc project (gdc) for four years. It debugs easily enough under gdb. Several editors support D syntax (including geany and vscode). It has quite a few libraries (though its interoperability with C libraries has muted native D library development somewhat), centralized at https://code.dlang.org/
Are there specific parts of the ecosystem you worry about not being mature?
As for it being a bit esoteric, yes, it's not a very widely known language, though I'm not sure why. I fell in love with it in 2018, and it has thoroughly spoiled me for writing C.
Maturity in a systems programming sense is different. Rust had a lot of effort pored (and still going) into the nostd variant to be used in bare metal applications like microcontrollers and kernels. Does D have that same level of formalism?
On a more serious note, I’m skeptical D would take. It seems like Rust has captured mind share and already has ongoing substantial work integrating it into the kernel (+ it’s the first and only non C language in kernel mainline). Given that context, I don’t see the motivation that works spur a similar level of support from kernel maintainers.
I'm sorry, but shouldn't we critique Dlang itself instead of the constant comparisons with Rust?
Dlang has had significant work poured into it, and the project has delivered a quality language with safety in mind. I don't mean to be defensive, but these threads always seem to ask the same question, it's boring at this point.
I think it's fair game to discuss Rust in this context since there's a major effort underway to support writing in-kernel drivers in Rust. Unless you think the kernel will be a bazaar of languages, then it's useful to think about which language is the most likely to "win".
There are other OSes out there where D could eventually make a mark.
Naturally the whole issue is that there is no big movement regarding writing OSes in D for that to matter anyway.
Better luck using TinyGo, Java, .NET or Oberon in bare metal workloads (where runtime plays the OS role), as there are a couple of products for them, than D.
> Rust had a lot of effort pored (and still going) into the nostd variant to be used in bare metal applications like microcontrollers and kernels.
D has had "dcompute" since 2017, for native execution on GPUs and other accelerators. People have been writing D for microcontrollers since at least 2011, possibly earlier. D is fairly mature in the systems space.
> I’m skeptical D would take.
Maybe, maybe not. Some languages "click" better than others for individual programmers. It's good to have options.
> it’s the first and only non C language in kernel mainline
Do you foresee it being the only non-C language used in the kernel forever?
> Do you foresee it being the only non-C language used in the kernel forever?
It's possible that maybe the maintainers are just trying out Rust to see if it can be wrangled into the kernel to start the migration process. So now may be the right time to explore other languages.
Once a next language is "chosen" then yes, I do think that there will be only 1 language for the kernel itself (modulo the very long transition time to convert all components so you'll have C + 1 other language). I wouldn't be surprised if at some point the kernel decided they're not going to accept any more C drivers because driver code is a lot more variable in quality and lower in oversight and testing. Core kernel code will take a longer time as even now that's out-of-scope for most such efforts.
One big issue with D compared to Rust for performance-oriented code is the lack of move semantics. Rust and C++ idiomatically almost never rely on copy-on-write, whereas D so far has a lot of it. I'm not sure how much this matters for kernel modules, but I imagine that it is something users would consider. I had seen some proposals for move semantics in D, so for all I know this is under works right now.
My framework laptop has served me very well for the last year or so. This is one of the few pieces of open source hardware that is genuinely better (IMO) than many other larger hardware brands. The entire device is just so well built and the upgrade path is so well defined.
I jumped on the System76 train initially and feel burned. I'm looking for an alternative for my next machine. Its gotta actually have functional battery life next round. I expected a firmware update at some point from system76 to resolve this and it basically has never happened.
I just got issued a System76 at work and I thought I must have configured something wrong.
On one hand, I guess I'm glad it's not me; on the other hand, I wish it was just some dumb config toggle ("terrible_battery_life enable") that I could flip back to get more than a few hours of working time, or ~48 hours in my briefcase with the lid closed (!!!), before it was dead as a brick.
It's like the early 2000s all over again, where the battery just got you from one outlet to the next.
I feel bad even saying anything, because I like the company and Pop_OS and what they're trying to do in general. But damn, that's a big flaw to just ship products with in 2022.
I love the form factor, but the battery is my second biggest gripe with my Framework (after fractional scaling still not supported by many apps). Even after tweaking settings ad nauseam, I cannot get the suspend battery life to last more than 12-16 hours.
If that's for an 11th gen model, that's taking into account the problems with HDMI/displayport extensions, and either not using them, or using the beta firmware update?
The limited suspended battery life is admittedly rather annoying for me as well, but it doesn't seem as bad as it is in your case.
The killer for me is USB-A. Each draws about half a watt while the laptop is suspended, more than it usually draws when the laptop is turned on! With a 55 Wh battery, that really eats into your standby time (although I still usually get multiple days).
I disagree with the author regarding their complains surrounding rich people going through life easier. Unfortunately that will always be possible and complaining about it muddied this article
However, I agree with the author that a private company should not be getting between me and my government. I am okay with TSA as long as it is my government making sure airports are safe. I am fine with paying more for expedited passports because that is a deal between me and my government. I am fine with expedited boarding because that never involved my government and it never should.
This is a situation, like the author said, that is similar to the intuit catastrophe. Paying CLEAR is equivalent (in the long term) to ensuring that no forward progress is made on simplifying and expediting airport security.
That’s a valuable distinction you are pointing out. I agree 100% in theory. For example, on certain municipal websites in New York City where I live, credit cards are not natively accepted for transactions, but a link is provided to an authorized private company who charges a non-trivial commission. This is problematic.
On the other hand though, I returned yesterday from a business trip to Israel, where taxes fund a highly functional and adequate healthcare system, but many well-to-do tech workers also pay for private health insurance which allows your family members to be seen almost immediately by a specialist when needed. I would be okay with this system in the United States as a compromise to supersede the dysfunctional system we have now.
This is a beautiful (hacky) demo of something that I didn't think was possible in Rust (yet). I hope other applications don't accidentally start using it just to discover that it doesn't work in release mode.
Also, if you don't like the new layout, you can get the old one back. If you create an account, and go to preferences -> appearance, you can change back to the old "Vector Legacy (2010)" layout [1]
[1]: https://www.howtogeek.com/866617/how-to-get-the-old-wikipedi...