Hacker Newsnew | past | comments | ask | show | jobs | submit | c-hendricks's commentslogin

title is actually "Ruby already solved my problem"

Thanks, that helped. My unspoken question when I saw the title was "does that mean you now have two problems?".

Luckily me and my partner are all Apple, so even though the smart home is backed by Home Assistant, our interface to it is via the Home app (or Siri)

Apple doesn't make water heaters, A/Cs or furnaces, and I don't think most people would junk their own because it doesn't know how to integrate with Matter.

Yeah they all use the same palette, but they don't all use the palette the same way.

And copy / paste, "hm does this TUI intercept mouse clicks, ah it does, oh what was the key combo for my terminal emulator that allows to skip that? Crap I pressed ctrl-c instead of ctrl-shift-c". Or worse when you want to select text in a column-based TUI and your terminal emulator doesn't have any sort of column-selection handling.


> it's requirements are pretty opinionated (Ubuntu LTS 22.04 or 24.04

Hm?

> This guide describes an installation of Infinite Scale based on Ubuntu LTS and docker compose. The underlying hardware of the server can be anything as listed below as long it meets the OS requirements defined in the Software Stack

https://doc.owncloud.com/ocis/next/depl-examples/ubuntu-comp...

The Software Stack section goes on to say it's just needs Docker, Docker Compose, shell access, and sudo.

Ubuntu and sudo are probably only mentioned because the guide walks you through installing docker and docker compose.


If the developers can only get it to run in a pile of ubuntu containers, then it's extremely likely they haven't thought through basic things you need to operate a service, like supply chain security, deterministic builds, unit testing, upgrades, etc.

I see 6 officially supported linux distributions. I don't know where anyone got the idea that they can only get it to run on ubuntu. It's containerized. Who cares what the host os is, beyond "it can run containers"?

Here's where I got it from: https://doc.owncloud.com/ocis/next/depl-examples/ubuntu-comp...

And I wish it was "containerized" but really it's "dockerized" as this thread demonstrates: https://central.owncloud.org/t/owncloud-docker-image-with-ro...

So yeah like I said in my original comment, for personal use it's just not right for me (because I choose not to use docker in my personal projects), but I hope it's right for other people because it looks like a killer app.

I'd definitely like to see what other options are available on other distros so I'll dig through their documentation more.


I think what you're looking at is: "Here's an example of installing this on ubuntu 24.04. These instructions will also work on 22.04." This is in no way saying they can only get it to work on ubuntu; they just haven't written a step-by-step example like this for other distributions.

And yeah, trying to use podman with something that's based on docker compose is ... probably gonna give you some headaches, I'd guess. I don't particularly know the pitfalls but if you're expecting it to be transparently swappable, I don't think that's an owncloud issue.


I agree -- they chose their platform (docker), and for my personal work that just isn't my platform, and it's probably unfair for me to call them "opinionated" about that (because like it or not Docker is the norm) or about Ubuntu, especially in light of where I was getting my information from.

I've seen some flame in this community, but damn this thread has just been a bunch of polite people helping correct the record.


Your second link appears to be about OwnCloud, not OwnCloud Infinite Scale.

Dang, looks like wouter does the same thing as react router v6+ and nested routes don't get all params / paths of the route. ~~Also doesn't have react router v5's route-string typescript parsing.~~

https://github.com/molefrog/wouter?tab=readme-ov-file#route-...


> Also doesn't have react router v5's route-string typescript parsing.

It does, assuming you're talking about automatically parsing "/foo/:id" and getting a typed "{ id: string? }" route params object out of it? Wouter does that when using typescript.


Thanks for the correction, after looking at the types I'm guessing it's this bit: https://github.com/molefrog/wouter/blob/v3/packages/wouter/t...

Yep! That's the type. It used to be a lot more complicated if I remember correctly, but looks like the author is importing a type from that "regexparam" package to do it now.

Can someone explain what "just works" when compared to other networking gear? IE I use ASUS and their mesh, and it all "just works". Have a mix of routers over 10 years and they all mesh together.

I started with TPLink gear in a mesh mode, and it kinda sorta maybe worked? I had an access point on the ground floor, a range extender + option to connect RJ45 (for devices with out WiFi), on the middle floor, and an additional meshed AP / range extender on the top floor. The top floor meshed thing basically didn't work, the RJ45 thing got me like 50 Mbps while wireless was getting me 200 Mbps. It 'just worked', but it didn't work well.

In that same house switching over to Ubiquiti just worked, and worked well. I had the same setup (mesh nodes on every floor), but performance was substantially better (2-4x).

I've moved house, and now have wired APs on every floor, and get phenomenal performance. The management UI to see what is where / how its connected, and when something doesn't work is very good. It also enables things that were hard / difficult with other non-'prosumer' gear. Like I can have multiple WAN ports, and plug in a cellular modem, so that when my internet doesn't just work (which happens way too often) it auto-fails over to the cellular modem, and continues just working.

The reason I went with Ubiquiti in the first place was their Unifi Protect line of cameras, and again those 'just work' from the wireless small ones to domes / etc plugged into wired connections they all just seamlessly connect to my dream machine, and provides a great UI, and the data is on prem which I want.

The only thing Ubiquiti doesn't do the way I want is DHCP + DNS, so I have a seperate raspberry pi doing that.

After years of fussing around with either linux / pfsense / ... routing + firewall solutions, and different AP / meshing configurations the ubiquiti stuff is very hands off.


Ah, so based on your last paragraph I guess you're in "prosumer" territory? My router has dual WAN, SFP, can do cellular over USB, tells DHCP clients to use the pihole for DNS, and I don't have speed issues in or around the house with the mesh nodes, but maybe it falls short if I was looking to do more advanced routing/firewalls.

Definitely in prosumer territory, and it's totally achievable with equipment that isn't Ubiquiti (they're not magic, the mediums RF + ethernet + fiber are all the same), but the amount of fiddling I found to get things to 'work right' with ubiquiti was plug it all in, set up the WiFi password, and update the DNS / DHCP server to my pihole, and then I didn't have to do much else, and there was a really nice UI with nice metrics, and a nice UI for cameras all built in, and a few other niceties like some VPN options. There's also sufficient logging that when something doesn't work I can maybe figure out why.

I don't really do more 'advanced' routing (other than maybe the unifi protect aka camera stuff it sounds like we're describing similar configurations), it's just that when I tried to achieve the configuration you're describing with Asus it was impossible, with TPLink it took a lot of fiddling / configuration and never 'worked right' (right meaning as well as I thought it should, though I've not tried TPLink in a primarily wired configuration) where as the ubiquiti stuff was plug and play and just 'worked right' (close to the speeds and reliability I expected both in a mesh mode and in wired).

The whole camera thing -- which is what really got me to pay the ubiquiti tax -- is another story entirely, I'm sure there are lots of other good options for self hosted IP camera solutions, but I couldn't find any ones I wanted to use, and again with ubiquiti it was super plug and play, and once I'd bought the UDM to do camera stuff and saw how well that worked I wanted to try the ubiquiti networking stuff, and it worked better with less configuration that the other alternatives I'd tried.

With infinite time and finite budget ubiquiti is not the right choice for home networks, with a sizable budget for home networking equipment minimal time investment and a preference for performance ubiquiti has worked out better for me than alternatives out of the box, and better for me after spending time tweaking and trying to optimize TPlink (meaning ubiquiti out of the box was better after trying to optimize TPlink).

If "not ubiquiti" works for you out of the box, or in the configuration you're already in then you're all set, and you're definitely not missing out on anything. If things aren't working out of the box and you're tired of fiddling with it, or your other goals aren't possible, and they are with ubiquiti maybe it's worth the investigation.

I also _hate_ how much I sound like an ad for ubiquiti. I'm really not, but I think I've spent more time writing these two comments than I've spent having to fuss around with my network equipment in years.


Hey, really appreciate the response though. I would say I'm in the "more time than money" category.

It's hard to not notice the ... ubiquity of praise for their gear over the years, but I haven't seen much clarifying what sets them apart. Maybe I should look at them like peak Apple but for networking gear?


Yes. That is how I view them, and a fair description I think.

When I was willing to spend time on this (home networking + cameras) I would have never touched this equipment. It was all open source / cheap stuff with BSD or Linux routers, random switches, home assistant raspberry pi's connected to USB cameras. It would take some time maybe not a lot, but enough, and it would break frequently enough due to some update somewhere or something.


I think the idea is that the Ubiquiti equipment is far more capable than normal consumer-grade equipment like ASUS, and still manages to "just work". So your ASUS may also "just work" but is has a fraction of the capabilities as the unifi system in terms of feature load-out and scope of native device integrations.

Adding a new Unifi device to the network is just a matter of powering it up, responding to "adopt this new device?" prompt on your phone, and that's it. It's literally Plug'n'Play in 2025. Even if other brands let you do that with similar number of steps, the UX is so behind that it's impossible for you to discover the steps that easily. Ubiquiti uses UX quite intelligently to make complicated things feel simple. My experience hasn't been close to Ubiquiti's with any other brand I've tried.

For a start I wouldn’t trust brands that by default market mesh over wired backhaul.

Because ... ? Reminder my comment was looking for explanations. Is your issue that mesh + Ethernet backhaul is actually WAP + roaming and not mesh?

If the screen is off, what's to burn in?


nothing because that is a screen saver. but yeah you're right, it's probably mostly people who just want to see a visualization? i'd never argue screensavers are a logical choice lol


There's nothing about "use server" that requires it to be at the top of the file though, it can go in function bodies and you have a typed RPC method.

I think "use client" is the only one that has to go at the top of a file.


You are correct. Use server can be slapped in many places


I generally put lint rules to prevent casting, why cast here instead of declaring `props: (keyof SomeObj)[]` or `props: Parameters<typeof someFn>[0]`?


Er, my justification was that the code in question was meant to be minimally demonstrating someFn, and adding an import or a verbose type seemed to distract from that a little.

But mostly it just gave me a chuckle. I tried it because it seemed logical, but I didn't really think it was going to work until it did..


Inversely, plenty of people use GUIs for all of those things.


Yes, I agree, and have no qualms with people who prefer GUIs. But to say that "majority of users (developers?)" prefer GUIs seems outlandish at best.


I am the only person in my 10 person team that prefers the cli for stuff like git and while the ratio was a little more balanced during my time at college, it was still skewed towards GUIs. I don't think its unreasonable to think that developers might prefer GUIs over CLI


Many developers are on Windows, and those tend to prefer GUIs. CLI reliance is mostly a macOS/Linux thing.


I know some window developers use use WSL for all of their devving, and they are obviously gonna be working through the terminal.


I use Jetbrains git pull etc since they dont fail on modified files and other problems.


Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: