In fact, Intel has been a stellar contributor to the Linux kernel and associated projects, compared to all other vendors. They usually have launch day Linux support provided that you are running a bleeding edge Linux kernel.
Rust or not, mixing two different languages within a single project is a sure fire way for a maintenance nightmare. Specially for a large project like Linux. I sincerely don’t want something like that happening to the Linux kernel. Just let it die with C. However it may seem improbable, writing a kernel from scratch is the way to go for new wanna be system programming languages.
Isn't this due to inherent limitations of native binaries? Java has very few native dependencies, so its trivial to do binary dependencies. Besides, most packages in maven central have their sources in there as well. You can easily download the source package and let the debugger use that.
Why these pension plans needs to be so complicated? 8% from the employee, 15% from the employer. Paid to a separately managed fund each month. That's how its being done where I work.
Isn't this just another case of RH (and Canonical to some extent) screwing Fedora users to make their paid offerings better? As far as I understand, this is not gonna be enabled by default on RHEL. If this is a must, it shouldn't be harder to produce two different builds or two different ISOs. People who needs profiling can grab the ISO with profiling enabled. Us regular folks can use the one without.
Asking out of curiosity. What's your rationale behind Spring is slower? Worked on couple of greenfield and existing Spring Boot applications and we never had any performance issues caused by Spring. Spring has its own bad parts but calling that it has worse performance than Java is not one of them. Its not even a valid comparison. Java is crazy fast for a VM based runtime AFAIK.
Sometime back, I had a rapsberry pi connected to wired network of a coworking space. I remember using autossh to keep a tunnel open with one of my VPS. Mainly used it as a torrent box. I added magnet links through qbittorrent webui installed on raspberry pi. Qbittorrent was configured to only run at night time to not cause issues for business work. Downloaded all sort of things easily reaching thousands of GBs throughout my time there. They never found out. Or they didn't care to look. Good times.
As I founnd out myself, there is almost no tinkering involved once you get the initial Arch setup done. Just update once a week. Fedora repos have considerably fewer packages than Arch or Debian. For some reason Redhat land has always been off putting for me. SELinux, dropping docker in favor of podman, CentOS debacle are just a few things that make me look elsewhere. I'm glad you found your sweetspot though. Just a friendly banter from a fellow Linux user.
No one in their right mind would think this is going to be a smooth ride. The massive amount of capital required to build cutting-edge fabs is a hard pill to swallow. These news writers need to cut Intel some slack. The world needs cutting-edge fabs in geopolitically stable locations. I believe Intel is simply too critical to fail at this point, and, as always, Uncle Sam won't let them.
This is a proof that both politicians and economists are clueless perhaps on purpose. How about getting rid of this tipping thing as a whole? It has essentially became a way to scam customers.
I don't think that's possible without a jump server. If all peers are NATed, there is no way doing p2p without a jump server. WebRTC is a giant rabbit hole itself.
Good luck getting timely mainline Linux support if ever. Rockchip usually provides an ancient patched kernel without much willingness to upstream their changes. They usually leave things for the community to sort out. On the other hand, x86 has the best mainline support which you can count for awfully long time to be around.
I hope Intel continue updating/improving their low power offerings like N100. It has been a great little CPU so far. ARM ecosystem seriously lags behind x86 in terms of standardization. Hunting down ISOs for devices other than popular ARM boards gonna be impossible once the vendor ends supporting their heavily patched Kernel. Seems like that the ARMified future is not gonna be the rosy dream as vendors want us to believe.
Yeah kind of. But configuring them is a chore that not everybody got an appetite for. Plus WMs lack the convenience apps which proper DEs provide out of the box.
Although this feels like a ok-ish approach to just serve API docs to users, you are missing the whole point of specs if you use this approach. I have started to extensively use spec-first approach with open API. You wouldn't believe how many hours it saved for me despite the initial cost of time to get things started. For example, No need to tediously write DTOs ever, just have them generated using API spec. Need an SDK for API consumers, just generate an SDK using the spec for almost all the popular languages. While using Open API as just an API documentation is fine, it is a waste of potential that Open API provides.
Instead of releasing a bunch of half-baked hardware, Pine64 should focus on getting a decent level software support for those devices. OG PinePhone is 2 or 3 years old now, and still has crappy software support. At this point, it is reasonable to assume that Pine64 devices are a scam.