HN user

cantagi

173 karma
Posts0
Comments58
View on HN
No posts found.

They have been removing features from the open source version for a while.

The closest alternative seems to be RustFS. Has anyone tried it? I was waiting until they support site replication before switching.

I have a problem with the Github Actions documentation. There is a lot of it, but it feels as though it was written from a "product" perspective, to explain how to use the product.

None of it usefully explains how GHA works from the ground up, in a way that would help me solve problems I encounter.

UK resident here. The original version gave me the push I needed to get a rPi 2B+, subscribe to a VPN, and use it as a wifi AP that routes all traffic from my house through it.

Can you trust a VPN who say they don't log? No, but more so than an ISP who might be legally required to at any moment without you ever finding out.

Also, I will now never start a tech company in the UK, and this is because I will never put myself into a position where I am forced to add backdoors to a product.

TBH I haven't ever had a problem with SD card corruption so far. If I did, it wouldn't really matter, since all the important data is on the RAID array, and the OS can be reprovisioned if needed.

Performance proved to be an issue for SD cards though, when attempting to host nextcloud and postgres. I do what teh_klev is talking about and selected the fastest USB stick I could find, which was a Samsung FIT Plus 128 GB Type-A 300 MB/s USB 3.1 Flash Drive (MUF-128AB), and this gave me a huge speedup.

Unfortunately Jellyfin is not really fast enough on an rpi and I have no solution.

The range is indeed poor, and it depends a lot on your house/flat. Would definitely recommend using another machine with something like this.

In terms of throughput, right next to an AP, I just got 65Mb/s.

I have 3 rpi4s running my entire home network.

One is a vpn router and a wifi AP, it also has Uptime Kuma. I need this to be reliable and rarely touch it except to improve its reliability. - Openvpn - HostAPD - Uptime Kuma (in docker) - A microservice invoked from Uptime Kuma that monitors connectivity to my ISPs router (in docker) - nginx, not in docker, reverse proxies to Uptime Kuma

The second acts as a NAS and has a RAID array, consisting of disks plugged into a powered USB hub. It runs OpenMediaVault and as many network sharing services as I can set up. I also want maximum reliability/availability from this pi, so rarely touch it. All the storage for all my services is hosted here, or backed up to here in the case of databases that need to be faster.

The third rpi runs all the rest of my services. All the web apps are dockerized. Those that need a DB also have their DB hosted. Those that need file storage are using kerberized NFS from my NAS. This rpi is also another wifi AP. This rpi keeps running out of RAM and crashing and I plan to scale it when rpis become cheaper or I can repair some old laptops.: - Postgres - HostAPD - nginx - Nextcloud - Keycloak - Heimdall - Jellyfin - N8N - Firefly-iii - Grist - A persistent reverse SSH tunnel to a small VM in the cloud to make some services public - A microservice needed for one of my hobbies - A monitoring service for my backups

All of these pis are provisioned via Ansible.

To me it's been obvious ever since the term SaaS was coined, that it would be worse for users. Not only is it more expensive, you don't get control over your data or how you use the product. The idea of cloud computing is similar - you have to pay more for someone else's computer. Granted, SaaS and cloud computing make sense if you're an organization, and can have advantages in terms of scale, reliability, etc.

But also, when business interests get involved in producing software in general, it often causes problems, i.e. ads, worse interop, performance considered unimportant, marketing emails, DRM, the software not working after the company is acquihired or fails. However, producing software takes time which costs money. So, commercially produced software can only exist at this intersection between there being a business model, and the software being useful. The condition is, the usefulness must be enough to be worth paying for, and the result is what we have now.

Imagine rewinding to 1990 with unlimited borrowed VC funds, hiring every person employed in tech full time until 2023, and building a massive suite of useful software for individuals, companies, govt, with a few different alternatives for each use case (like we have now), except they communicate via a series of well defined and public APIs. The entire software stack would be developed in this way, for maximum usability, performance, interoperability, features, etc. . After getting to the set of features we now have in late 2022, we pause the thought experiment, note the date, and split the cost between the users. Ignoring the various practical issues with this experiment, I bet it would be possible to get to where we are sooner and far cheaper per user.

Long story short, I don't think the goal of making money as a business is very well aligned with the goal of producing really good quality and long lasting software, even if the users are willing to pay, and this is a real problem. For personal use, I won't tolerate ads, DRM, etc., so I now self host.

Yes, people writing unmaintainable code in Jupyter notebooks is a problem.

Personally, I start every notebook with

    %load_ext autoreload
    %autoreload 2
then develop production quality code in .py files.

Why bother with docker for a home server other than for the fun of it?

I do this. Over time you forget how each service was configured, or simply don't care. Adding more and more stuff to a home server increases the complexity and the attack surface more than linearly in the number of services.

I run nearly all my home services in docker, and I have a cookie-cutter approach for generating SSL certs and nginx config for SSL termination (not dockerized). Provisioning is automated through ansible, so my machines can be cattle not pets, as far as is possible on 3 raspberry pis.

I also found it very weird, but here's my intuition.

There are 2^k > 512 spheres stuck to eachother across k-d (pretend k=9). The line from the center to the point where the inner sphere touches one of outer spheres has to shortcut through all k dimensions to get from the center to the sphere.

This distance has been massively inflated due to the number of dimensions. But the distance to the edge of the box hasn't been inflated - it's just constant, so the inner sphere breaks out.

The fourier transform is the same for all time, and the time-series contains all frequencies, so it makes sense to plot them on orthogonal axes. However it makes sense for them to share the 3rd axis for magnitude.

However, the Im parts are just bolted on orthogonally to the Re parts and orthogonally to the magnitude. The reason the Im part of the time series shares an axis with frequency is just because the author ran out of dimensions.

Since a commercial fusion reactor hasn't yet been developed, you can't argue that it is or will be the same cost per-megawatt as fission power. That's because you can't predict any advances in technology that make fusion easier or reduce the capital cost.

Based on a HN recommendation, I read this book: https://www.amazon.co.uk/Future-Fusion-Energy-Popular-Scienc...

The authors argue that ITER will get there and it's a matter of time, funding, and politics. SPARC might be able to get there around roughly the same time. Neither will be hooked up to the grid, but they will demonstrate the tech needed to make a viable fusion power plant. Unfortunately none of the other exciting fusion projects out there will be able to get off the ground due to fairly fundamental limitations.

If you ignore any tedious jokes about when fusion power will be ready, and assume it will be ready in a few decades, it's still a process that converts reasonable quantities of seawater into power, with no CO2 emissions, and is relatively safe compared to fission.

It won't be ready in time to reduce emissions enough to prevent catastrophic climate change. However, it can be ready soon enough to power the devices we'll need to sequester CO2 from the atmosphere once we've reduced our emissions to the point of diminishing returns.

After the concept has been demonstrated, there's plenty of scope for improvement which will make it better and cheaper. On the other hand, the price of oil will increase as emissions taxes are introduced (I hesitate to say that we'll run out of reserves).

There's a lot more mileage in fission technology that what's commonly deployed for power, but the new types of reactors needed make it far easier to produce weapons(). Also, although fission technology is mature and safe, the human factors around it are not, which will still lead to accidents, contamination, and deliberate theft.

() Fusion reactors would also make it possible to breed fissile material since they are a neutron source but it would be slower and easy to detect.

Why could an airship not be made using a vacuum instead of a lifting gas?

A quick google reveals that someone has thought of this before: https://en.wikipedia.org/wiki/Vacuum_airship and it seems like it might not be possible with currently available materials.

Would it be possible to reduce the density of helium for the same pressure by electrostatically charging it to make the molecules repel, effectively turning the airship into a giant capacitor with alternating +ve and -ve sections?

Great post!

I once had to port a siamese neural network from Tensorflow to Apple's CoreML to make it run on an iPhone. Siamese neural networks have a cross convolution step which wasn't something CoreML could handle. But CoreML could multiply two layer outputs element-wise.

I implemented it using a fourier transform (not a fast fourier transform), with separate re and im parts, since a fourier transform is just a matrix multiplication, and convolution is element-wise multiplication in the fourier domain. Unsurprisingly it was very slow.

I'm not a roboticist, but can the ability to do general purpose manipulation be built up from a universe of known simpler manipulation tasks using something a bit like transfer learning? Is this used? Are there methods that don't need this?

Also, what would a good interface between a Software 1.0 program and a Software 2.0 program look like in robot software? I mean, what would the boundary between (3) and (4), and (4) and (5) look like in this imaginary stack?:

  (5) Autonomous controller (software 2.0)
  (4) A high level interface for giving instructions to (3), and finding out what (5) is doing
  (3) Motor manipulation controller (software 2.0)
  (2) A daemon for converting NN outputs into safe hardware control outputs (software 1.0)
  (1) OS kernel (software 1.0)

I once tried to reproduce a webcam PPG paper, but not using Eulerian video magnification.

The pipeline started with face detection, then found the mean colour value of a rectangle of forehead. It then did some DSP and returned the pulse frequency.

It worked, but only when the person held extremely still very close to the camera, with auto exposure turned off.

Disappointed with how badly mine worked, I took a look at some open source webcam PPG projects to find out how they were working. It turns out they were pretty similar, except most of them were aggressively filtering the pulse signal to be in the correct range, without really checking there was already a signal there. Of course by taking white noise signal and filtering it to a certain frequency range, you'll get a signal in that frequency range.

I now believe that to make video PPG work, you need some of (1) a very good camera, i.e. not just a low end webcam (2) quite a long recording, i.e. 10s-1m (3) a controlled environment

After the new interface was brought out, I found that the most jarring thing was how the left-hand-side menu collapsed down left to a set of meaningless icons, then when you hovered over it, it expanded right to cover important details of the actual emails.

Either I disabled it using some obscure setting or Google fixed it within a few days. I wonder if they knew people weren't going to like the update, and intentionally added temporary extra annoyances with the goal of acclimatizing users to the smaller and more profitable annoyance of the "AI" autocomplete and autorespond. The cynicism comes from having been a Facebook user.

EDIT: typos

ROS beginner here. I've been experimenting with ROS in my spare time for about a week, with the ultimate goal of building a trainable robot. So far, I've built a custom robot arm in gazebo, converted it to URDF, and hooked up gazebo to ROS. The next step is to start controlling joints.

A few years ago I tried to run a project based on ROS and gave up in the end due to compatibility problems (I was installing ros packages on top of an existing Ubuntu and it caused all kinds of problems). Now that I'm using their pre-built docker image and took the time to read the tutorials, I'm finding it more reliable and much nicer.

The tutorials are very clear and all the steps have "just worked" for me, although the individual packages don't always seem very well documented.

catkin doesn't seem like a heavyweight build system - more like an opinionated layout combined with some cmake macros and some scripts, built on top of cmake. I can see how this would be useful for myself as well as real roboticists to develop multiple packages in parallel without having to poke through complex and disparate build systems. A robotics student would want to dive into C++ or Python as fast as possible as opposed to figuring out the build system, and I think catkin serves this purpose.

Also, it's common for inexperienced linux/mac users to get confused between multiple installations - when they have to compile things from source, i.e. opencv. I wonder if the ros command line tools are partly designed to help students overcome that obstacle, i.e. the pattern roscommand packagename rosoptions.

I'd also argue against the added complexity of avoiding single points of failure during early stage robot development. Having to think about distributed systems and SRE would be a huge distraction from the already complex task of designing a robot and its software. I also very much hope that ROS isn't currently being used in self-driving cars without a lot of safety systems including hardware ones.

The piece that falls to Earth ends up wrapping faster and faster, this causes centrifugal force on the tip, increasing the tension in the ribbon. Often the ribbon breaks on its way down and some fragments go flying out of Earth's gravity well. I didn't expect this at all.

The space elevator would become a space whip. I wonder whether this has a use case, like getting hardened unmanned space probes to speeds required for interstellar missions, or just much faster missions to other planets in the solar system.

If Facebook's business model is built around collecting and selling personal data, and more than 4% of their revenue globally comes from EU citizens, then they could decide to wilfully flout GDPR and just pay the maximum fine every year.

Another way they could deal with it is by disputing the EU-US privacy shield[1] or disputing the decision that overturned the original privacy safe harbour[2]. IANAL so I have no idea how they would do this, but it will be costly for ECJ and FB.

[1] https://en.wikipedia.org/wiki/EU-US_Privacy_Shield [2] https://en.wikipedia.org/wiki/International_Safe_Harbor_Priv...

Glad Apple have finally put coremltools on Github. It looks like they've added a lot of stuff recently as well.