I've self-hosted more or less everything from the get-go back when I was working at a telco which provided me with a 4 Mb/s fixed line back in 1996. One of the first things I did was change to a self-hosted mail server with my own domain, the rest quickly followed. Just to name a few, used daily:
- Proxmox to run all mentioned services
- Software router to bind them all together (OpenWRT in a container)
- Database services (Postgresql, Mysql, Redis) used for many of the mentioned services
- mail services (Exim, Dovecot, Spamassassin, greylistd, dovecot-managesieve)
- web-related things (first Apache, then lighttpd, then nginx) running:
- "Cloud" (first Owncloud, then Nextcloud) with functional equivalents of e.g. Google Docs (Nextcloud Office), Google Reader (Nextcloud News), Google Meet (Nextcloud Talk, Jitsi Meet), Gmail (Rainloop app in Nextcloud, Roundcube), Google Maps (OSM app in Nextcloud), Calendar etc.
- Wiki (first Twiki, then Mediawiki, now Bookstack)
- Media (mpd, Airsonic, Jellyfin, Peertube, Pixelfed)
- version control (first CVS, then Subversion, then Gogs, then Gitea)
- Search (Searx and Recoll)
- big-tech proxies (Invidious, Nitter, libreddit, Spodcast, searx (see Search))
- Video surveillance (Zoneminder)
- Remote application/desktop service (X2go, NoVNC, now experimenting with Kasm)
- "Chat" services (first Prosody, then ejabberd, then back to Prosody)
- Timelimit service + app on my daughter's phone to keep her screen time in check, I can remotely give her more time when required
- a "stable" and "development" build server (Debian running in containers)
- ...and a lot more
Basic services are divided over a few containers - base, mail, auth. Most services run on a single container - serve. Some get their own container because they are only started irregularly (bookcook, the bookkeeping service) or they should be separated from the rest - p2p, session (remote application/desktop services). I tend to shun docker, preferring to tailor services to my own needs. Currently the only services using docker are Kasm Workspaces [1] and some linuxserver.io instances which I'm experimenting with.
[1] ...with the database (postgresql) and cache (redis) services being redirected to the 'base' container which runs all database services
If ever you get tired of Google - and for those who get tired of Apple or Amazon or whomever they have entrusted their digital photo archiving needs to...
Any of the personal cloud things - Nexcloud, Owncloud, Seafile, Syncthing and others - can be used to sync files - and with that photos and videos - from mobile devices to some server somewhere. This can be the server-under-the-stairs, your NAS at home, a wall-wart with a Raspberry Pi and a drive taped together, a VPS or a commercial entity offering these as SaaS. You can keep using your phones with or without Google, that is up to you. If you run the stuff yourself you'll need to install and configure the parts which make it work, if you use a commercial instance you just have to install the relevant app and tell it to sync your data. You can do this in parallel to using Google Photos, just to make sure you have a backup in case Google wants just that one extra piece of personal data to allow you to access your photos which makes you give up on them. Just one more piece... and one more please...
Who gets to define the group and who gets to define what is good or bad for the group? Who gets to decide who is in the group and who needs to be cast out? Who gets to speak for the group?
Have a look at the history of politics and pay special notion to those strands which centre around grouping people, whether that be "proletarians versus capitalists", "those_who_belong_to_my_religion versus those_who_do_not", "those of our nation versus those from elsewhere" and now this "those who belong to my identity group versus those who do not".
Also have a look what most of these group-centred ideologies have in common, namely the identification of a specific scapegoat group which is blamed for all the woes - including those caused by the application of the group-centred ideology - which beset the in-group. In Bolshevist Russia is was the Kulaks [1], in Nazi Germany it was the Jews, in theocratic Iran it is "the great Satan" (i.e. the USA and its allies) while in this new "woke" cult it is the "cis-gender heterosexual white man".
The problem with all these group-centred ideologies is that groups do not have a voice, only individuals posing as the group do. Those individuals can gain a lot of power and as such either tend to get corrupted or are drawn to the role of spokesperson because they already are corrupt. Group-centred thinking works well on a small scale - family, small neighbourhood, etc - but it often fails when the members of the group no longer personally can know each other since that makes it possible for the corrupt spokespeople to make their play.
While I agree to most of the glued/soldered/planned obsolescence criticisms related to applethings I do feel the need to point out those "obsolete" macthings tend to run Linux just fine. I should know, writing this on a 'late 2009 27" iMac' which I got for free due to its video card being broken (which it is no longer, 8 minutes in the oven at 195°C is all it takes) running Debian. While it is also possible to get more recent versions of macOS to run on these things this is not nearly as easy nor useful as running Linux which just supports the hardware without any qualms. Apple does not want you to use older hardware so they don't build macOS for machines which are perfectly capable of running it. Installing unsupported versions is made possible by monkey-patching the release in a rather hit-and-miss fashion, often leaving parts of the hardware (bluetooth, sound, wifi) without or with sub-standard support. All this while Linux runs flawlessly on the same hardware.
Depends on which one you're using, mine contains a Radeon HD 4670. There is a lot of NVIDIA on the PCI bus but this does not seem to be an obstacle to the thing running flawlessly:
There is some Broadcom as well - the Bluetooth controller, which works fine - as well as some Qualcomm - the wifi controller which, again, works fine.
This is a 'Late 2009 27" iMac', running the internal display as well as an external 1920*1200 24" monitor through a DP->HDMI cable. Everything works, including the silly IR remote control thingy (tested using the IR blaster on my phone).
> I wish more linux laptops had the build quality and support of macbooks
I'm glad my "Linux laptops" are very much not like those macbooks with their glue and solder and "no user-serviceable parts inside (and we really mean it)"
> This isn't a rant from an Apple fan, this is a rant from a laptop fan. ThinkPad's aren't good laptops despite what the guy with the pocket protector says. They are flimsy and feel cheap. They still have 20th century tech (eraser mouse, c'mon!). They are my grandfather's laptop.
The good thing with those machines is that you'll be able to keep on using your grandfather's laptop while those whose grandfathers opted for macbooks are left wanting. I'm using a T42p from 2005, apart from putting in an SSD I have not changed the thing. It was, and still is, a perfectly useable tool.
Funnily enough the Framework laptop is nothing like 'glue and solder' (it's designed for repair and upgrade, with extremely well thought out captive screws and magnets) but does have I would say 'the build quality and support of Apple laptops'.
Support even better in a way, since they'll just ship you a replacement part rather than charge you through the nose for 'Framework Care' only to tell you it's old and needs replacing, can trade in if you want or send it off for weeks to have a 'refurbished' (not new) part fitted.
Drop Twitter, Facebook, Instagram, Youtube, Tiktok, NYT, WaPo, Fox and all those other creators of permanent anxiety. Take up farming, buy a plot of land and build your own house, create something. Realise that:
- the climate has always been changing and it always will but humans and most other species survived. It takes an extinction level event to make a big dent in the biosphere
- social inequality is far less now than it has been in earlier times when people often lived or died at the whim of some aristocrat
- there is no shortage of workers, only a shortage of people who want to do a given job for a given reward
- there have always been 'billionaires' and there will always be since having a lot of resources makes it easier to gain more resources. Some billionaires do interesting things with their resources, others lie on them like Smaug. As long as there are enough resources left for the non-billionaires I don't care about them other than doing my best to not feed them if I can
- the media is rubbish. Don't criticise the media, be the media. Corporate media doesn't bite the hand that feeds it so just avoid them (see above).
- corruption is everywhere and has always been, it is not for nothing that Utopia was named so - it does not exist. Just like I try not to feed the billionaires I try not to feed corrupt institutions, occasionally breaking a law or two instead of giving in to their demands. That means they have a stick to hit me with if and when they want but knowing that they always will be able to find that stick means it doesn't make any difference to me
Eventually we will but it will take a shake-up of the market by an outsider who does not have an existing business based around cars priced at current levels. Electric cars are far less complex than ICE-based vehicles so there is no real reason for them to be more expensive. The current excuse for their high prices is the cost of the battery pack but battery prices have been on a downward trajectory for a long time now. Eventually a newcomer will find the lure of selling an EV for half of the lowest priced competitor too large to ignore and the rest will be history. That newcomer will be derided by the existing sellers and the media which depends on advertising income from those established actors but that attack won't succeed if the increase in price-performance is large enough.
Proprietary vs. open is like renting vs. owning without the legal protection offered to renters. If your data is locked in some proprietary format you're beholden to the proprietor who can - and often does - abuse his power by raising prices, adding intrusive 'features', selling access to your eyes and more. No EULA is going to change that since those agreements can be changed more or less at will.
There is nothing about proprietary licensed software that requires it to use proprietary data formats. There also exists FOSS software using esoteric formats. You can, and probably should, know how software is going to store your data before you use it, no matter what license it has.
Check how often guitar-pro changed their format for no perceived benefit. Corel didn't even support svg, last time I checked (years ago, admittedly).
The point is: a locked proprietary format is in the interest of proprietary software vendors. It benefits the vendor but hurts the user.
The vendor can even make something document well enough to be used by governments but closed enough to be impractical to be freely implementable. See ms office formats.
That’s not because of the license, though. Both the license choice and the hostile formats are caused by the author being hostile.
The authors point here isn’t that all companies that use proprietary licenses are good. It’s that a proprietary license doesn’t have to make you bad.
For B2B users, there are often FOSS terms that they find to be hostile. Limitations of liability being a big one. Waiving one’s right to use the legal system is a big deal to some people. FOSS programmers like this because it protects them. But for non-developers, this only limits their own rights.
> For B2B users, there are often FOSS terms that they find to be hostile. Limitations of liability being a big one. Waiving one’s right to use the legal system is a big deal to some people. FOSS programmers like this because it protects them. But for non-developers, this only limits their own rights.
That's only if you don't pay someone for a support contract. I've never seen a support contract for FOSS that waived liability.
If you want someone to be liable, you can pay them for the privilege, just like with proprietary software. And you don't have to just choose the original developers. This gives the end users more rights, not less as you're suggesting.
You can certainly buy support contracts but they tend to accept liability primarily in regards to their support capability, not the total extent of what the law would otherwise allow. While FOSS may convey rights that proprietary software doesn’t, those rights are not necessarily valuable to any one user in particular.
This is why people choose different licenses. A software engineer in their dorm room cares about different things than an accountant in an office.
I've never seen a support contract that conveys all liability the law allows. In general the more you spend the more the lawyers get really specific about what SLAs, etc. actually mean. And the baseline is never 'the developer is responsible for everything'. This is just as true for FOSS and it is for proprietary software.
And to talk about FOSS as happening in dorm rooms is 90s level FUD.
It's also simply not representative of what's being discussed. Support for FOSS is a many billion dollar industry, and describing it as happening in dorm rooms is absurd.
I understand that. The statement was intentionally an example of an outlier, not making a generalization as you accuse.
There is, in fact, at least one person in a dorm room writing FOSS. (I've been one, myself) And there's at least one person in an accounting office who does not write software. These are examples of two individual people who have different needs. This is not a generalization of any industry as a whole.
You haven't given a stronger plausible interpretation than spreading FUD. Your only defense so far is that it was a non-representative fact bordering on a non-sequitur.
"There is nothing about proprietary licensed software that requires it to use proprietary data formats."
All that matters is the fact that if you can't see the code then you can't implement the format unless the developer degns to give you specs, and doesn't lie about the specs. And the fact that, in practice, what actually happens is, proprietary software takes every opportunity it can possibly get away with to vendor-lock data.
It doesn't matter that they don't have to, what matters is that they do, and, you have no option to take matters into your own hands when the vendor doesn't please you.
"There also exists FOSS software using esoteric formats."
This is a stupid statement. By which I mean it invalidates it's own self.
When the source to generate some data is a available, it doesn't matter what the format is. No matter how complex and disorganized or "esoteric" the data, and no matter how terrible the source code that generated it, and even no matter how old or obscure the language or platform used, it still exists as a reference. That simple existence is the difference between possible and not-possible, and that is all the difference in the world. That difference is 1000x more important than any level of convenient vs inconvenient.
"esoteric" is a meaningless word in the presense of x-ray goggles.
The data remains usable and interoperable no matter what it is. It doesn't matter if it's common or onscure, or current or ancient, or human-readable or encrypted binary, and no one has the power to deny you access to read the data or to generate compatible data from outside of the original app, and regardless of the original developer's intentions.
There is no slightest shred of a valid argument here.
What? Why are you even trying to say that those constitute access to the source in any meaningful way to anyone?
Yes proprietary licensing does preclude source availability, obviously, because no one has access to those source licenses, and the few that do, have to sign nda's preventing them from publicising what they see. If someone is working for someone huge enough to actually have one of those source licenses, they can't use it to fork and publish a fixed version of the product, or even publish open source code to merely interoperate if the details end up disclosing inner workings indirectly. Whatever they get out of it, it doesn't do anyone else any good, and that fact itself means it doesn't even do them as much good as it could.
There may be some products where the vendor charges less than millions of dollars, because not all products are Adobe
CS or the PS5's os or Turbo Tax etc, but so what? The proprietary license itself defines the most important fact, which is who retains the right to grant and deny access and usage. The fact there may exist some products where the vendor happens to be small or cooperative means nothing at all, because others are not, and even the ones that are can and do change the deal at any time.
Those licenses don't matter, because the licensees are no different than employees. The employees who develop a proprietary product can also see the source. The special licensees are no different.
Saying the option to get one of those licenses means the source is available, is like saying you could always get a job at that company and the source would be available.
This is a baffling argument to even try to float. Not merely that the argument falls apart instantly at the first glance, the more remarkable thing is I can't imagine why anyone would even want to try.
> Yes proprietary licensing does preclude source availability, obviously, because no one has access to those source licenses, and the few that do, have to sign nda's preventing them from publicising what they see.
The people who are a party to shared source licenses, have access to the source. There licenses are very meaningful to those who use them. They might not be beneficial to you, but that is likely not their concern.
FOSS software can also be subject to NDA. In fact, this is not uncommon. Many companies use Apache/MIT/GPL software, use the software internally, and have their employees sign NDAs.
"The people who are a party to shared source licenses, have access to the source"
So do the employees of the original vendor. So what? How does that matter at all? It means nothing and has no bearing on this topic.
"FOSS software can also be subject to NDA."
Bwhahh wut? No. And I mean, by definition, no.
An organization may take some foss and use it internally and hide that modified internal version, but that means nothing to anyone else. They can't nda the original software they forked from, and they can't even nda their modified version unless the original happens to be MIT-like or they never redistribute it.
There is a lot of MIT software which doesn't require sharing back, but that still doesn't change anything.
Their private mods are no different than anything else they write privately. Whether the private thing is a diff off of a public thing, or something standalone, makes no difference and has no bearing on the original public thing. Their new private thing, if it is nda'd, is then by definition, not foss. It doesn't matter that it's comprised of a copy of some other foss plus whatever they added. It's now just some proprietary software like any other.
None of that harms anyone else or makes foss somehow just as limited as proprietary or proprietary just as available as foss.
> "The people who are a party to shared source licenses, have access to the source"
> So do the employees of the original vendor. So what? How does that matter at all? It means nothing and has no bearing on this topic.
The title of this topic begins with: "EULAs Aren't Inherently Evil"
My point is that, FOSS only provides benefits to users who care about modifying or redistributing that software. Not everyone does. Giving my mother the right to modify and redistribute software does not provide any tangible benefit to her, because she will never do that.
For the many institutional users who take advantage of shared-source licenses, they also have no desire to redistribute or change the software, they simply want to audit it. They are not being prevented from doing anything that they wanted to do.
What evil is done to a user when you take away a right to do something they had no desire to do? And for that matter, why is taking away people's tort rights something that is assumed to be good for users?
I personally appreciate and contribute to FOSS, but the idea that it protects the rights of anyone other than developers specifically is myopic.
Just like proprietary licenses restrict the rights of users, so do almost all FOSS licenses -- just in different ways. The difference is not that one protects your rights and the other one doesn't, the difference is in which rights they choose to protect.
> There also exists FOSS software using esoteric formats.
They're esoteric, but not proprietary. The article is making the argument that with proprietary agreements you can pay someone for support. With FOSS, that's also true with the added benefit that the market for support isn't impeded by the artificial barrier of IP access.
That is the theory, now look at the practice of proprietary software/services and see if the theory holds. It clearly does not, one of the bigger problems with proprietary IT is the lock-in caused by undocumented data formats, services which do not allow bulk data extraction and similar obstacles.
You can do the same lock-in with most FOSS licenses. There’s no requirement to under any common license to document the code. And under the vast majority of them, you can deliver it as a service and be exempt from distributing your code too. Or, you can lock people in with complexity that, while anyone could legally expand on your code, they practically can not.
Data conversion may be a big cost factor in a small software deployment, but in a large deployment, it may only be a small portion of switching costs. There are a lot of switching costs that FOSS simply doesn’t address, particularly when labor, compliance, or legally related.
Pull the thing out of the house and let it burn outside. It is a relatively small battery so outside it won't do much harm, this in contrast to what it seems to do in that room. Tossing it in the pool is also possible but given the small size that'd be a waste of pool water which would need to be replaced. Just let it burn outside. Use a rake, broom or whatever other long thing at hand to pull the thing outside.
I made a rack out of some dumpster-dived supermarket shelves, lumber, a couple of truck air filters and a forced draft fan. The thing doubles as drying cabinet for produce (mint, mushrooms, fruit etc.) by having the equipment in the top half of the rack followed by an air flow divider and 8 rack-sized metal-mesh-covered drying frames. From top to bottom the thing contains:
* HP ProCurve 2910al-24G J9145A 24 port Gigabit switch (managed switch, €47)
* HP DL380G7 with 2xX5675 @3.07GHz, 128GB (ECC) RAM and 8x147GB SAS drives (€450)
* NetApp DS4243 (24x3.5” SAS array, currently populated with 24x650GB 15K SAS drives (4 as inactive spares), €400)
* the mentioned airflow divider
* 8 drying frames
It is managed through Proxmox on Debian and runs a host of services including a virtual router (OpenWRT), serving us here on the farm and the extended family spread over 2 countries. The server-mounted array is used as a boot drive and to host some container and VM images, the DS4243 array is configured as a JBOD running a mixture of LVM/mdadm managed arrays and stripe sets used as VM/container image and data storage. I chose mdadm over ZFS because of the greater flexibility it offers. The array in the DL380 is managed by the P410i array controller (i.e. hardware raid), I have 4 spare drives in storage to be used as replacements for failed drives.
The rack is about 1.65m high, it looks like this (here with the old D-Link switch (now deceased) and minus the DS4243 array which now sits just above the air flow divider):
In the not-too-distant future I’ll replace the 15K SAS drives with larger albeit slower (7.2K) SAS or SATA drives to get more space and (especially) less heat - those 15K drives run hot. After a warm summer I added an extra air intake + filter on the front side (not visible on the photos), facing the equipment. This is made possible by the fact that cooling air is pulled through the contraption from the underside instead of being blown in through the filter(s).
I chose this specific hardware - a fairly loaded DL380G7, the DS4243 - because these offered the best price/performance ratio when I got them (in 2018). Spare parts for these devices are cheap and easily available, I made sure to get a full complement of power supplies for both devices (2 for the DL380G7, 4 for the DS4243) although I’m only using half of these. I recently had to replace a power supply in the DL380 (€20) and two drives in the DS4243 (€20/piece), for the rest everything has been working fine for close to 4 years now.
On the question whether this much hardware is needed, well, that depends on what you want to do. If you just want to serve media files and have a shell host to log in to the answer is probably ‘no’, depending on the size of the library. Instead of using ‘enterprise class’ equipment you could try to build a system tailored to the home environment which prioritizes a reduction in power consumption and noise levels over redundancy and performance. You’ll probably end up spending about the same amount of money for hardware, a bit more in time and get a substantially lower performing system but you’d be rewarded by the lower noise levels and reduced power consumption. The latter can be offset by adding a few solar panels, the former by moving the rack to a less noise-sensitive location - the basement, the barn, etc.
As to having 19" rack equipment in the home I'd say this is feasible as long as you don't have to sit right next to the things. Even with the totally enclosed, forced-draft rack I made the thing does produce enough noise to make it hard to forget it is there.
After the stack has taken what it needs there are 35 solar panels left on the barn roof. Excess heat is used to heat the upper floor, given that it is well-insulated it needs no additional heating. Problem, solved.
Selling that excess power is possible, as is buying some extra panels - there is enough space for at least 36 more on just that single roof. For now I choose to add panels - and batteries in the not too distant future, once the market is flooded with used EV-batteries - and continue on my course of decentralising the 'net using 'old' hardware - not a single new product is used in any of my computing endeavours. Most of it is either dumpster-dived and repaired, bought 2nd hand or acquired through places like Freecycle.
I also like recycling electronics but some stuff is just not worth keeping powered on. If you can sell electricity back then your switch has an opportunity cost of (assuming 11¢/KWh, which is US avg for 2021 and 5W idle for the replacement switch) ≈45 USD/year, which is almost 90% of its value.
- Proxmox to run all mentioned services
- Software router to bind them all together (OpenWRT in a container)
- Database services (Postgresql, Mysql, Redis) used for many of the mentioned services
- Backup services (rsnapshot, custom backup scripts)
- mail services (Exim, Dovecot, Spamassassin, greylistd, dovecot-managesieve)
- web-related things (first Apache, then lighttpd, then nginx) running:
- "Cloud" (first Owncloud, then Nextcloud) with functional equivalents of e.g. Google Docs (Nextcloud Office), Google Reader (Nextcloud News), Google Meet (Nextcloud Talk, Jitsi Meet), Gmail (Rainloop app in Nextcloud, Roundcube), Google Maps (OSM app in Nextcloud), Calendar etc.
- Wiki (first Twiki, then Mediawiki, now Bookstack)
- Media (mpd, Airsonic, Jellyfin, Peertube, Pixelfed)
- version control (first CVS, then Subversion, then Gogs, then Gitea)
- Search (Searx and Recoll)
- big-tech proxies (Invidious, Nitter, libreddit, Spodcast, searx (see Search))
- Video surveillance (Zoneminder)
- Remote application/desktop service (X2go, NoVNC, now experimenting with Kasm)
- P2P services (Transmission, IPFS, MLDonkey (when needed))
- "Chat" services (first Prosody, then ejabberd, then back to Prosody)
- Timelimit service + app on my daughter's phone to keep her screen time in check, I can remotely give her more time when required
- a "stable" and "development" build server (Debian running in containers)
- ...and a lot more
Basic services are divided over a few containers - base, mail, auth. Most services run on a single container - serve. Some get their own container because they are only started irregularly (bookcook, the bookkeeping service) or they should be separated from the rest - p2p, session (remote application/desktop services). I tend to shun docker, preferring to tailor services to my own needs. Currently the only services using docker are Kasm Workspaces [1] and some linuxserver.io instances which I'm experimenting with.
[1] ...with the database (postgresql) and cache (redis) services being redirected to the 'base' container which runs all database services