lpribis · HackerTrans

> Space in NYC isn't cheap. Space in space is free.

... what?

Say what you want about starship etc etc, but space in space is far from free and will be for a long time.

lpribis

il y a 11 joursdiscuss

The UK loves to take various infrastructure and industries private and public depending on which government is in power at the moment. See also trains, water, etc

lpribis

il y a 14 joursdiscuss

I would like to know if text is LLM generated even if I can't tell from the content itself. For me it's a matter of attention (hah) and a quality signal. The poster expects to spend a minimal amount of effort on the post, and all the readers will have to spend the same amount of attention whether its LLM generated or not.

To me, it's disrespectful to expect someone to waste their day reading every word of a blog post when even the author has not read every word. It shows that you value your time over your reader's time.

lpribis

il y a 15 joursdiscuss

False equivalence, text processor leaves the authors intention completely in tact and is deterministically controlled completely by the author. Not true for gen ai

lpribis

il y a 22 joursdiscuss

Also bit twiddling is very useful in a scientific language when you want to "simulate" a lower level embedded processor, typically fixed or floating DSP or controls code. For example MATLAB/simulink are very commonly used as a high level language before porting the algorithm to a DSP, FPGA, or ASIC, and for this they support bit twiddling and integer/fixed point arithmetic.

lpribis

il y a 26 joursdiscuss

Faster than rustc (the main rust compiler written in rust). Obvious from the context.

lpribis

le mois dernierdiscuss

Bitbake (Yocto's build system) started originally as a fork of portage (gentoo package manager), but they have diverged a ton. Very similar concepts though.

lpribis

le mois dernierdiscuss

> My experience is that Yocto is a bit like CMake: people hate the mess they make with it and blame the system, even though they never bothered learning to use it.

I agree this is true a lot of the time, speaking as someone who has made many Yocto messes and later regretted. But you also can't discount all of the messes made by silicon OEMs that you are forced to deal with to use their SoCs.

E.g. I recently did a project with Yocto on a Zynq US+. Look at the meta-xilinx layerset (or, God forbid, petalinux) and tell me they haven't made a complete mess of it.

The complexity and lack of upstreaming in kernel and userspace for so many of these SoCs, coupled with non standard boot process and devicetrees means you will be forced to use these terrible OEM layers. I don't think a new build system can fix this at all, it's a cultural/commitment that needs to change from the OEMs.

At the end of the day, of you are doing any complex embedded Linux work as a small team, you must use Yocto because it's what the OEM supports. I don't have time or resource to debug DFX not working because some userspace tool was built with slightly different flags than expected by the flaky ass xilinx upstream.

lpribis

il y a 2 moisdiscuss

Are you seriously suggesting hobbyists should tapeout an ASIC instead of use an FPGA?

1. For one-off designs (quantity=1) ASICs will never beat a high end FPGA on unit price.

2. As a hobbyist, you want to EXPERIMENT. You cannot do that with an ASIC. Hobbyists want to do something simple, test it on real hardware, and slowly build up from that. I don't have the time nor expertise nor motivation to spend months writing verification to get it right the first time for a tapeout.

"Just use a microcontroller"... I will concede that microcontrollers do cover 90% of hobbyists use cases (that number increasing by the day). But for hobbyists sometimes you want to learn HDL or digital logic or computer engineering. You can do this hands on with a FPGA much more effectively than in software.

> It's probably cheaper for them to maintain Windows for one reason or another.

They already need to maintain the Linux build for all the other paid tiers?? These are the same software with different features locked behind a license key. It costs them NOTHING to keep the build enabled for free tier.

lpribis

il y a 3 moisdiscuss

How would that help? Unless you happen to check the dotfiles git diff before running _anything_. I guess this could be put in prompt or some cron job to detect diffs but I bet absolutely nobody does this.

lpribis

il y a 3 moisdiscuss

> Middle management is where the institutional knowledge sits on how to actually get shit done despite challenges & broken processes/systems.

Really? In my experience it's the rank-and-file employees who have this knowledge of how to get on with it without ceremony and politics. And the broken processes and politics are created BY the middle managers.

lpribis

il y a 3 moisdiscuss

I have worked with a lot of people who had this attitude. The main predictors for it in my experience are

1. Lack of faith in the company they work for, ie they don't fully "believe in the vision"

2. Love of tinkering and programming

I haven't noticed age factoring in at all. Working far far away from ant tech hub areas might be a factor as well.

lpribis

il y a 3 moisdiscuss

> On your side-project it's also ok to ignore best engineering practice, reinvent the wheel because you feel like it or make decisions based on what seems most interesting even if it's not a 'good' decision.

Pro tip for enjoying your life at work: this also applies to you work projects. Once you realize this, you can have a lot more fun at work and even coerce work projects to be more like your for-fun/side projects. Of course this is detrimental to the company as a whole, but your company almost definitely does not care about you and you might as well extract as much enjoyment as possible.

If your coworkers are actually passionate about programming (i.e. not drones or PM brains running flowchart to increase quarterly profit), you can even make work more enjoyable for them.

Things like unconventional language choices, over-engineering of systems, unusual coding styles, obscure protocol/library use, and of course a ton of NIH can really spice up a mundane codebase.

Even stretching an "easy" module into a masterfully crafted program and going 4x over estimation can be fun sometimes (without any of the bad design choices suggested above).

Yes I stand by this bad advice, and it's allowed me to play with so much technology I would never otherwise touch at day job.

lpribis

il y a 3 moisdiscuss

I'm pretty sure he has used gradient descent in previous videos to optimize systems, maybe this time it was just easier to hand tune rather than set up an optimization feedback harness around MuJoCo.

lpribis

il y a 4 moisdiscuss

I was curious what information I could glean from these for some popular repos. Caveat: I'm primarily an low-level embedded developer so I don't interface with large open source projects at the source level very often (other than occasionally the linux kernel). I chose some projects at random that I use.

*Mainline linux*

Most changed files: pretty much what I expected for 1 and 2... the "cutting edge" of Linux development over other OSes -- bpf and containers. The bpf verifier and AMD GPU driver might get a boost in this list due to sheer LoCs in those files (26K and 14K respectively). An intel equivalent of amdgpu_dm is #21 in the list (drivers/gpu/drm/i915/display/intel_display.c) and nvidia is nowhere to be seen (presumably due to out-of-tree modules/blobs?).

    186 kernel/bpf/verifier.c
    174 fs/namespace.c
    162 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
    161 kernel/sched/ext.c
    159 fs/f2fs/f2fs.h

Bus factor: obviously none. The top 4

    10399 Christoph Hellwig -> I only know his name because of drama last year regarding rust bindings to DMA subsystem
     8481 Mauro Carvalho Chehab -> I also know his name from the classic "Mauro, shut the fuck up!" Linus rant
     8413 Takashi Iwai -> Listed as maintainer for sound subsystem, I think he manages ALSA
     8072 Al Viro -> His name is all over bunch of filesystem code

Buggy files: Intel comes out on top of GPU drivers this time (twice). Along with KVM for x86(64), the main allocator, and BTRFS.

    1477 drivers/gpu/drm/i915/intel_display.c
    1406 MAINTAINERS
    1390 sound/pci/hda/patch_realtek.c
    1102 drivers/gpu/drm/i915/i915_drv.h
     943 arch/x86/kvm/x86.c
     928 mm/page_alloc.c
     871 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
     862 drivers/gpu/drm/i915/i915_reg.h
     840 fs/btrfs/inode.c

*GCC*

Most changed files: IR autovectorization code, riscv heuristics tables, and C++ template handling (pt.c is "paramaterized types").

    152 gcc/tree-vect-stmts.cc
    145 gcc/config/riscv/riscv.cc
    131 gcc/tree-vect-loop.cc
    116 gcc/cp/pt.cc

Buggy files: DWARF debuginfo generation, x86 heuristics tables, RS6000(?!) heuristic tables. I had to look up RS6000, it's an IBM instruction set from the 90s lol. cp-tree.h is an interesting file, it seems be the main C(++) AST datastructures.

   1017 gcc/dwarf2out.c
    885 gcc/config/i386/i386.c
    796 gcc/cp/cp-tree.h
    740 gcc/config/rs6000/rs6000.c
    720 gcc/cp/pt.c

*xfwm4* Most changed files: the list is dominated by *.po localizations. I filtered these out. Even after this, I discovered there is very little active development in the last few years. If I extend to 4 years ago, I get: 1. src/client.c - Realizing this project is too "small" to glean much from this. client.c is just the core X client management code. Makes sense. 2. src/placement.c - Other core window management code.

This has not told me much other than where most of the functionality of this project lies.

Bus factor: Pretty huge. Not really an issue in this case due to lack of development I guess.

    3298  Olivier Fourdan
     530  Anonymous
     319  Xfce Bot
     121  Jasper Huijsmans

Files with bug commits: Very similar distribution to most changed files. Not enough datapoints in this one to draw any big conclusions.

I think these massive open projects (excl xfwm) are generally pretty consistent code quality across the heavily trodden areas because of the amount of manpower available to refactor the pain points. I've yet to see an example of "god help you if you have to change that file" in e.g. linux, but I have of course seen that situation many times in large proprietary codebases.

lpribis

il y a 4 moisdiscuss

I don't think any realistic system will bootstrap C from shell. What is the shell implemented in if not C?

lpribis

il y a 5 moisdiscuss

He implied replacing nano was the first step, before using it for more complex (software development) tasks. First use it just for quick one-off edits of /etc/blah.conf then graduate to using it for longer editing sessions.

lpribis

il y a 5 moisdiscuss

Rather than being about fast/simple/cheap, I think using SSN as a key was more about the fact that SSN is the only common identifier that almost all US citizens have.

lpribis

il y a 6 moisdiscuss

Sure, but splitting "atomic" operations across a reboot is an interesting design choice. Surely upon reboot you would re-try the first `mv a b` before doing other things.

lpribis

il y a 6 moisdiscuss

This is local to the device though. Nothing to do with the WAN. Would still work even on the "serverless" ipv6 network.

comments