• 1 Post
  • 26 Comments
Joined 3 years ago
cake
Cake day: June 12th, 2023

help-circle
  • I’ve seen people mention this a few times, but I’m not so sure that it’s actually a thing.

    Switches are designed to route traffic intelligently, and they don’t blast all of the traffic to every port. If I remember correctly, at some point they do some kind of mapping between IP address and MAC address, and they know which MAC addresses are attached to which ports, and they only route the traffic to the port that has the MAC address they are looking for. I don’t know how much local switches collude with each other to share information about connected devices or how many hops they may be able to look into.

    In any event, no matter how wrong I am about that, if you’ve got a device on switch A that needs to send packets to a device on Switch K, then Switch A either has to know that the device is on Switch K and the path to get to Switch K or it has to send the packet to every switch that it is connected to. That doesn’t change with VLAN’s, if Switch A doesn’t have knowledge about every other switch on the network, and which VLAN’s they are configured for, then it will have to send the packet to every switch it is connected to.


  • Compose is great for Android because it’s so integrated with the ecosystem. For desktop applications, JavaFX - especially coupled with Kotlin - is a clear winner to me.

    I should point out that I don’t use FXML or SceneBuilder, but code all of my layouts in Kotlin. Kotlin features like extension functions let you eliminate 90%+ of the JavaFX layout boilerplate.

    Back to Compose. Both Compose and JavaFX are Reactive GUI environments, although many (most???) people don’t realize that about JavaFX. But both environments take opposite approaches to Reactive design.

    Compose, as the name implies, uses what I call “compositional reactivity”. This means that the actual layout is totally static, but is recomposed, in whole or part, in response to changes to the data representation of state. That code will look at the various State elements each time it runs, and alter the layout according to their current values.

    JavaFX uses “Reactive Layouts” (my term, again). JavaFX has a comprehensive, yet extensible, collection of Observable data types and another comprehensive, yet also extensible, collection of Bindings to allow you to connect them together in any way that you can think of.

    Every configurable element of every screen Node in JavaFX is expressed via these Observable values, meaning that they can be bound in some fashion - in either direction - to elements in the State data structure.

    The result is that it JavaFX the layout code is run exactly once. But this layout code not only performs the actual layout, it also creates the bindings to State. After that, the layout behaves dynamically all my itself.

    In JavaFX, layout composition is actually quite expensive in terms of performance, and recomposition is to be avoided if possible - and it is virtually always possible. I have seen people bitch about JavaFX being “heavyweight” and raggy, and I can guarantee you that those people are just doing a lot of recomposition.

    The biggest challenge to programming, and I say this with more years of experience than most people reading this have been alive, is in understanding the underlying paradigm that governs whatever language or toolkit they are using. Unfortunately, you unlikely to open up a book or webpage and see, “The underlying paradigm of this technology is…”.

    That’s especially true of JavaFX. It takes a LOT of time to realize the Reactive nature of JavaFX by yourself. Consequently, I don’t think that JavaFX gets recognized as the desktop application powerhouse that it is. As someone who has mostly mastered it, I’m constantly amazed at how trivial it is to build truely complicated applications with JavaFX.


  • Do your smart switches talk to your HomeAssistant server???

    Or does your HomeAssistant server talk to the devices?

    It’s probably the latter, and in terms of network security the difference is huge. You can restrict your smart switches to their own, untrusted zone with no outgoing permissions and then give HomeAssistant access to them from its zone.

    I would also argue that your personal devices and desktop computers are far more sensitive than your HomeAssistant server.






  • As an example, I was setting up SnapCast on a Debian LXC. It is supposed to stream whatever goes into a named pipe in the /tmp directory. However, recent versions of Debian do NOT allow other processes to write to named pipes in /tmp.

    It took just a little searching to find this out after quite a bit of fussing about changing permissions and sudoing to try to funnel random noise into this named pipe. After that, a bit of time to find the config files and change it to someplace that would work.

    Setting up the RPi clients with a PirateAudio DAC and SnapCast client also took some fiddling. Once I had it figured out on the first one, I could use the history stack to follow the same steps on the second and third clients. None of this stuff was documented anywhere, even though I would think that a top use of an RPi Zero with that DAC would be for SnapCast.

    The point is that it seems like every single service has these little undocumented quirks that you just have to figure out for yourself. I have 35 years of experience as an “IT Guy”, although mostly as a programmer. But I remember working HP-UX 9.0 systems, so I’ve been doing this for a while.

    I really don’t know how people without a similar level of experience can even begin to cope.


  • I have an HP T740 running Opnsense and it works just fine. You can pick them up for about $100 USD, and they seem to come mostly with 8GB RAM, and a 64GB SSD. That seems to be more than enough for Opnsense, even running VPN’s.

    These are just a tad larger than my Lenovo M910Q Tiny servers, but they have a PCI slot, so you can put a second ethernet port (or 2, or 4) of whatever speed you like in it.


  • The question implies that the OP wants to create one giant filesystem with all of their data on it. This has its own issues, especially if it is in /home. For one, as someone else pointed out, it’s fairly difficult to run your system without /home mounted, and that makes it difficult to resize. Sure, you can set up an admin account with it’s home in the /root filesystem and then log into that - but that seems to be a lot of work in itself.

    If it was me, I’d set up mount points for file systems that make sense. Maybe /data/Photos, or /data/Music, or data/AppData, or whatever. As much as possible, I’d just point whatever software I was using to those new directories to find the data. If that isn’t feasible, for whatever reason, then a symbolic link from /home/Photos to /data/Photos will work seamlessly in most cases.

    As far as I’m concerned, after administering enterprise systems using Unix going as far back as the early 90’s, symbolic links are a key tool in managing disk space that you shouldn’t just dismiss because it’s “an unnecessary layer of complexity”. Having smaller, purpose designed, file systems allows you to manage them better. Sticking everything into /home is probably not the right answer for anyone.




  • That’s a little confused. From what I remember, it’s the server that matters, not the domain when being blocked. If you self-host this is a problem, but not if you use your own domain on a commercial service.

    The “MX records and such” are all a function of domain management. You’ll have to do this whether or not you self-host.