Hacker News new | past | comments | ask | show | jobs | submit | lproven's comments login

Hi. Article author here.

I worked for SUSE from 2017 to 2021. Because of that, I ran openSUSE on my work computer. Btrfs self-destructed on me, on 3 different PCs, about twice a year in that 4-year period.

Not myth. Not from t'Internet. Direct personal experience.

Btrfs `df` lies. You, and programs, can't get an accurate estimate of free space. OS snapshots fill the volume, volume corrupts, new install time. Over and over again.

I do not trust Btrfs and since the Btrfs zealots are in denial and will not confront the very real problems, I don't think it will ever get fixed.


There's an order of magnitude difference between running for a year and a decade... That's a lot.

A couple of years ago at work, we came across a Linux (virtual) server related to a customer project that had been running for some 2.5 or 3 years since the last reboot. Pretty much by accident. I think we rebooted it for good measure (applying security updates, making sure it still booted cleanly, etc.) but there was no immediate need for doing that just to keep it functional.

It's entirely possible that BSD is more stable and lends itself better to running for really long times uninterrupted. But Linux systems running for years really aren't unheard of, and by no means is one year the top of the range.

Whether you should do that is another question. Over the course of a decade, there could well be even kernel-level vulnerabilities discovered, let alone ones in other services running on top of it. You might have a system running without a reboot for years as long as you make sure to update (and restart) user space services as needed. But leaving an entire server unattended for years doesn't sound like a good idea generally.

That may not be as much of a concern if what the box is running is a limited set of services or functionality with little exposed surface. But that then comes more down to "what you're doing with it" rather than "which OS you're using".

The generally less conservative development culture around Linux leans more towards moving fast and breaking things, although generally while trying to avoid the latter. Perhaps that makes things like low-level OS vulnerabilities or whether the system still restarts cleanly after a decade more important in the Linux land, and what counts as prudent administration in Linux might be less of a concern in BSD.

But if you can have a BSD box running for a decade, with some particular set of services, in an internal network(?), and then compare that to someone else's report of a Linux box running for (at least) a year, in 1994 or 1995, probably running an entirely different workload, in a different environment (perhaps externally exposed?), and with no indication of why it may or may not have been restarted after that time, that's not really a fair comparison either.


Yep. Not rebooting for a decade is in most cases an irresponsible ‘advanced rookie’ move. I’m more than aware of the greybeard-era uptime fetishism. I’ve more than dabbled in it. I’ve typed /exec uptime into my IRC client more times than I dare admit.

But come on…

All that’s been said about security updates etc aside (some of which can be mitigated with that fancy in-place kernel update stuff), If something hasn’t rebooted in 10 years I’m going to be a bit nervous about what happens when it does reboot. If it’s in an uptime fetishist environment, chances are that it’ll be rebooted at a time that’s…inconvenient to say the least. Are you SURE that nothing has changed in that time? Some people are! Moreso than others at least. But that’s extra work, and my bet is most places with these high-uptime machines aren’t putting that work In, or think they are and are doing it poorly.


Well, yeah but also at this time Linux had not even been around half a decade.

My thought was more that maybe a lot of the issues people are having with Linux to push them to BSD is what we, developers collectively, have done to Linux over the last 2-3 decades.


This is my article -- but it's also a dupe...

https://news.ycombinator.com/item?id=41776849


Probably merged now

Only VirtualBox that I know of. Innotek originally wrote it for that task.

Not directly but a team is working on one:

https://clonos.convectix.com/


Oh, hey, that's mine. Thanks for posting it. I have stopped posting all my articles to HN since most weren't getting any attention.

BSD always seems to be a popular topic on HN.

I think there are a fair few BSD users here, and there are also a lot of us who wonder whether we should be using it for its boringness.

I think Marinelli's blog post was discussed on HN earlier: https://news.ycombinator.com/item?id=41732415


I use it on my desktop and I love the boringness. It's not constantly trying to push new stuff I didn't ask for (eg ipconfig to ip, systemd, snaps, etc). It's just sticking with what works. I like that. Linux distros try to reinvent the wheel too much for my liking.

> there are also a lot of us who wonder whether we should be using it for its boringness

Yes.


By the nature of innovation of products on platforms, most HN readers are noisily building experiments on top of things rather than quietly building the stable things underneath.

Pizazz is interesting when hyping the new new things; boring is interesting when hosting the world.

I'd guess it's not that you're not getting any attention, I'd guess the handful of global infra builders don't stand out in your stats.


> I'd guess it's not that you're not getting any attention

I am a humble reporter. I don't have access to most of the Reg's internal stats about who is viewing a page, from where, etc.

I'm just going by the fact that most of my HN submissions got no upvotes and no comments.

One commenter in another discussion said my subs were getting [flagged] and/or [dead] as spam. I only see one sub ever as being flagged. I think it was this one:

https://news.ycombinator.com/item?id=38445020

... Which as it happens did get lots of engagement, then AFAICS due to a misunderstanding of the title got edited, then it got flagged. But I do not know the details.

Saying that, I suppose it's possible that normally this is invisible to me somehow, or that others see stuff as dead that I can't? I don't know.


Yes, a LOT of your submissions are dead. Email hn at ycombinator com and they will surely be able to give you some insight.

Meh. I have just stopped bothering.

It was good fun. Happy I could be there.


* From the home of the prior market leaders in mobile phones;

* Presumably contains many former engineers from that company;

* From a free democratic EU state, not somewhere untraceable and not governed by Western laws;

* As a European product enjoys more legal privacy protection and security than either American or many Asian vendors.

Those are the ones that spring to mind.


* Not a yolo VC-backed project from Silicon Valley that becomes abandonware two years later.

:-) That too!

> I wish it was feasible to have alternative mobile systems, but it's not really.

I think there is a possible exception here.

I mean, firstly, yes, sadly this is largely true.

I had a Blackberry Passport, a beautiful handset running the QNX-based BB X OS. Over a year of ownership it gradually got less and less useful as app vendors turned off BB X support. No FB IM, no Whatsapp, and I have a phone that won't let me text with 90% of the most-contacted people on my phone.

And in those days (2014-2015) I did much less with my phone than now.

But I also own 2 little-used tablets.

I use tablets for watching films and TV, reading books, occasionally email. I don't do any of the mobile-phone stuff on my tablets, and they do not have SIM cards in them.

I would have as much use for a FOSS-powered tablet as I do for an Android or iOS tablet.

Poor patchy phone support does not cut it, sadly, and that's more than doubly so without apps.

But good support for at least one currently-available cheap Chinese tablet would be of legitimate interest to me.


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

Search: