Hacker Newsnew | past | comments | ask | show | jobs | submit | LinuXY's commentslogin

Zettlekasten with git and https://github.com/foambubble/foam - if I'm mobile I use WorkingCopy to paste links into an inbox file that I organize later.


IMO Zig right now is fairly buggy. And the rate of bug introduction has been greater than the fixing of said bugs over the past few years. (Not a knock on the project.) Move fast and break things. Trying to develop production quality software in Zig is like trying to hit a moving target. Zig is not production ready, and they mean it. The ABI is not stable and features are removed/retooled from version to version. (eg. removal of async.) This is all stated upfront, however. Zig is a WIP. That being said, if you've read the warning labels and are still excited there's /tons/ of promise. They are on the right track to being a modern C replacement/augment/mux with an integrated build system. And it's a joy to program in. And the community is pretty great. The best way forward is joining the community and contributing in one way or another, because Zig will be quite special once it's done. Bun is a clear indication of this.


I have fond memories of learning Pike and Roxen as a kid by perusing the Stellar Crisis source code (released, 1993!) I think there's still some servers around today. https://strategywiki.org/wiki/Stellar_Crisis


Yeah, in that same year I was using "LPC" in an LPMUD called "Lost Souls". I think that's a precursor to Pike, but I'm not certain about the family tree.

I had learned Basic when I was young, and my coursework had pushed me to learn Pascal and C, but I really think it's LPC that pushed me towards a career in programming.


Yes, I am also under the impression that Pike grew out of LPC (and I, too, really cut my teeth on LPC).



Another Roxen user by way of LPC (even have the T-shirt!). Back in the day, gtext was the bomb. Nothing looked as good.


SRE. Learning to build the automation that makes changing the kernel a change to a config file (Ansible/Salt/Nix/etc.) and pushing a button.


The NanoPi R4S has a RTL8169 controller with MSI-X capabilities. Post irqbalance setup I verified it's properly distributing IRQs. I'm using mine as a transparent bridge and network monitor. https://news.ycombinator.com/item?id=27236081

        Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-


Interesting, I'll have to check that device out. I'm using Raspberry Pi 4b and it does not have the right capabilities, ethtool just says the operation is not supported:

    sudo ethtool -x eth0
    Cannot get RX ring count: Operation not supported

I might have to add a NanoPi to my collection


Any chance we can get a scalable network backend to go along with the render enhancements? Fan-out workers on actors and a KCP implementation would great!


const std::string unusable = "unsuitable";


For more inspiration I'd check out the Quake engine source. It's quite the masterpiece. There's also been some modernization over the years by LordHavoc of the DarkPlaces engine https://icculus.org/twilight/darkplaces/ - I'm constantly impressed how well the HD remaster on DarkPlaces looks on modern 4k hardware.


The Wolf3D source is probably an even better start. Much simpler, the bad part is that it's 16-bit Borland C.

Andre Lamoth's DOS game programming books are a good read as well, he used 16-bit Microsoft C. Sprinklings of assembler in both.


I've never quite understood the allure of wanting to reinvent the wheel by creating a "distribution." There was one time where the Linux kernel did not support enough abstraction or a project was brought under some less open licensing that these niche "OSes" made sense. I would much rather see less package managers rolling other projects' packages and more unity on a single declarative platform. Today it's systemd vs SystemV, apt vs yum vs pacman vs... ad-infinitum. The Linux kernel is finally at a point where not every snowflake needs to be made. I'm waiting for the day where the concept of a distribution is rightfully pedantic. Maybe by then we may have a real shot at Linux on the desktop. A collection of packages not an OS does make.


Distributions were never meant to describe distinct OSs. The term literally describes a collection of packages: or “distribution of packages” to be more precise ;)

The point of distros was never about a limitation of abstraction at the kernel level. It was about different ways of packaging or user space tools; or about what tools came pre-configured as part of that particular package of Linux+tools. This is as true in the very early days of Slackware and Debian as it is now.

Personally I like the variety out there, I call it “choice”. I don’t like Ubuntu Desktop - I’m not taking anything away from those who do but it’s just not a platform I feel at home on. If the choice were “Ubuntu or nothing” then I’d probably be running FreeBSD. But because we have choice it means I can run whatever opinionated flavour of Linux I want and you can run whatever opinionated flavour you want - even if our opinions differ - and thus we all still run Linux.

The whole “Linux on the desktop” argument doesn’t make much sense anymore. We now have WSL, Chromebooks, Netbooks, Android tablets and GNU user space tools that run on OSX via homebrew and/or Docker. Not to mention various hardware vendors who do take Linux compatibility seriously on their laptops (even if they may not always ship Linux “out of the box”). Plus many of everyday GUI tools we use these days are now web applications because of how platform agnostic the wider computing landscape has become. So while we haven’t seen a surge of GNU/Linux desktops in the traditional Windows sense, I do think Linux / open source has already won in terms of breaking up the Microsoft monopoly.


It seems like you have some ideas you want to try out that involve system and community level decisions. If only there was a word for such a concept...


Minus CP/CMS and OpenVZ, here's an article on the concepts and tech Docker is built on. https://www.kentik.com/the-evolution-of-docker/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: