Hacker Newsnew | past | comments | ask | show | jobs | submit | more vbezhenar's commentslogin

> A tractor replaced a horse in turning the field, bit you still need a farmer to drive it.

Before mechanisation, like 50x more people worked in the agricultural sector, compared to today. So tractors certainly left without work a huge number of people. Our society adapted to this change and sucked these people into industrial sector.

If LLM would work like a tractor, it would force 49 out of 50 programmers (or, more generically, blue-collar workers) to left their industry. Is there a place for them to work instead? I don't know.


Fair point. The farms also begun to produce exponentially more food. If LLM’s would prove as revolutionary as Spinning Jenny and mechanisation of farm labour (which I don’t believe for a second), we could provide a easier life for billions of people, cure illnesses and poverty, provide education for countless children… The farm hands and their families moved to cities into factory work, which at least in England was dickensian horror of poverty and slums, but in many other countries (Nordic for instance) created urbanisation and new meaning of life as well as upwards social mobility. Many computer scientis here had a farmer as a grand-father or great-grandfather.

But none of this chamged how food grows and that you need somebody who bloody well knows what they are doing to produce it. Especially how machinised it is today.

However, I do not believe LLM to be a tractor. More like a slightly different hammer. You still need to hit the nail.


> pure android phone

Do these even exist? Last phones I'm aware about were Android One program, but it ended years ago.

The link suggests Google Pixel, but it's not pure android phone, it's full of Google junk software.


It's not an issue, it's just a price to pay.

I never used any actions and never understood why would I need to. I just wrote bash script to build my project and that's about it. This modern tendency to add dependencies for trivial things baffles me. You don't need "action" to do `git clone`.

bash scripts are as inscrutable as any GHA.

They are perfectly supportable and auditable as you're writing them yourself. It's just ordinary shell commands, there's nothing inscrutable about it.

Do you claim that there's a place where I can find datasheets for peripheral devices for Google Pixel? Like GPU, etc.

No, but they used to publish the source code for the drivers as part of AOSP. Now they no longer publish the device trees. Check out GrapheneOS' other Mastodon posts for the gory details.

I don't believe that's the true problem. Booting operating system is not a problem. There's no standardized hardware abstraction layer in PC either, every OS brings their own set of drivers.

My guess is that modern hardware is too complicated for one hacker to write reliable drivers. That wasn't the case back in the 90-s, when Linux matured. So we are at mercy of hardware manufacturers and they happened to not be interested in open upstreamed drivers.


> My guess is that modern hardware is too complicated for one hacker to write reliable drivers.

Modern hardware has turned our operating systems into isolated "user OS" nodes in the schematics, completely sandboxed away from the real action. Our operating systems don't really operate systems anymore.

https://youtu.be/36myc8wQhLo


Excellent and scary video that I share myself all the time.

In the ARM world, there isn't even a standard way to boot, and there are no standard hardware interfaces - except maybe the interrupt controller, since it's part of the CPU and only ARM designs the CPUs.

On any PC, you can still use BIOS/UEFI services to get a basic framebuffer and keyboard input. You cannot do that on embedded ARM devices - you need to get several layers into the graphics stack to have a framebuffer. I tried it on the PinePhone, using existing source code as a reference, and the furthest I got was sending commands from the video port to the LCD controller and then not having an oscilloscope to see if the LCD controller replied back.


I worked with ARM boards, I know a bit about it. Booting into Linux is never hard, it's all about using uboot, sometimes with tiny patches on top. I think it's actually even easier with android phones, as you don't have access to the low level bootloader, you just use fastboot stuff.

Having basic framebuffer in BIOS/UEFI is neat for toy OSes, but not very relevant for something practical. You gotta need proper driver for GPU. And if you're just starting, UART console is actually more preferable way to interact with board, IMO.


Booting into a mainline Linux kernel on your average junk-level SBC with all the hardware working (without simply sticking to an Android-like downstream/proprietary BSP) is quite hard, and that's what you need in order to make a phone usable as a daily driver. That's really the root issue; mobile phones are built as embedded devices, with no consideration for running a generic OS kernel. This isn't even an Android issue, OpenMoko was the same deal. If anything, Android was the first mobile platform to even loosely approach any kind of PC-like openness.

It all comes down to available drivers.

If drivers are available and you just need to write DTS to configure the driver, that's not a big issue. I don't think anyone thinks that Raspberry Pi has terrible Linux support, despite lack of UEFI, ACPI and all that stuff. Plenty of Linux distros support it well.


My issue with Github CI is that it doesn't run your code in a container. You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.

> My issue with Github CI is that it doesn't run your code in a container.

Is this not what you want?

https://docs.github.com/en/actions/how-tos/write-workflows/c...

> You just have github-runner-1 user and you need to manually check out repository, do your build and clean up after you're done with it. Very dirty and unpredictable. That's for self-hosted runner.

Yeah checking out everytime is a slight papercut I guess, but I guess it gives you control as sometimes you don't need to checkout anything or want a shallow/full clone. I guess if it checked out for you then their would be other papercuts.

I use their runners so never need to do any cleanup and get a fresh slate everytime.


I like AI changes. Can change files from UI, will fill commit message for me. That's awesome.

That was their gamble. Seems it didn't play out.

> You can just add the capability CAP_NET_RAW to your process, at which point it can ping freely

What are consequences of this capability? Seems like restricting this to root was done for a reason?


It lets you send raw sockets, and has some dangers (e.g. packet forgery). It's included in pretty much every container in existence (if you're running as root in the container or have ambient capabilities setup).

The goal of the capabilities system was to allow processes and users to gain a small portion of root privileges without giving them all.

In the "old days" ping on a Linux host would be setuid root, so it essentially had all of root's rights. In more modern setups it either has CAP_NET_RAW or the ping_group sysctl is used to allow non-root users to use it.


CAP_NET_RAW also allow to capture packets (tcpdump) so you really can have some fun like running a TCP stack in user space or MITM http connections: https://blog.champtar.fr/IPv6_RA_MITM/ / https://blog.champtar.fr/Metadata_MITM_root_EKS_GKE/

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

Search: