Bored? How about trying a Linux speed run?
rachelbythebay.com
rachelbythebay.com
#pepperidgefarmremembers
[0] Which is the point of Gentoo, after all. It's what made it a lot better than LFS/BFS. You get everything from source with little effort. 17 years later, I'm still using Gentoo. Nothing like it.
Might give it a try again.
I used Gentoo as my main OS for multiple years over a decade ago, installed it a couple of times, and helped with the localization of several documents, but I still remember the installation being basically the same as it is now.
I’m honestly wondering what is meant by this statement?
I failed at the chroot process at one point and ended up nuking a whole install.
I learned so much then though that has paid off in my career. Good times.
Incidentally, I had actually picked gentoo because the forums looked fantastic... My first linux attempt was with suse, but all the "interesting" answers were in German. So next time I tried the one with the liveliest forums. Turns out the forums were lively for a some of the wrong reasons (everything was hard), but the people were the right combination of friendly and incredibly helpful and knowledgeable. I learned a huge amount from the process and the people. Though, indeed, the whole from source distro thing was foolish, in retrospect.
Gentoo will forever be my "uphill through the snow both ways" story.
I didn't have cross-compiling set up yet, and I unwisely decided to install X. And Gnome. And Open Office.
It compiled for days.
(and, yes, I do remember waiting a full day for KDE to compile)
https://web.archive.org/web/20080704112619/http://funroll-lo...
Actually, probably quite the contrary. All x86-64 chips are required to support SSE2, which lets you use SSE for floating-point instead of x87 floating-point, which is a big speed win. But the newer extensions are specialized SSE instructions, which generally require manual use of instructions to utilize; specialized crypto instructions, which definitely require manual use; and AVX instructions, which doubles the width of vectors you can use. The first two is not going to be improved with -march; the code that uses it is almost certainly going to be compiled in a way that lets it dynamically use these instructions when available.
As for vectorized code that could use AVX instead, it's dubious how much of an effect it would have, since the biggest improvement in vectorization will be enabled with the 128-bit vectors, with 256-bit vectors offering at most a 2x speedup in the vectorized code, the effect being reduced by some code only being 128-bit-vectorizable (and not receiving any speedup), and also by Amdahl's Law reducing the benefit of further speedups in that code. Furthermore, vectorization tends to be much less relevant in the "integer" code that is typical of most consumer software, outside of a few hot loops that are already manually specified as above.
For hot kernels (say, memcpy), it is definitely the case that many projects have implementations of several different varieties of these, and use the version best suited for your current architecture. See https://sourceware.org/git/?p=glibc.git;a=tree;f=sysdeps/x86... for the different variants of common functions in glibc.
> Illustrated on the Motorola MC68HC11 ... Copyright 1991
http://pygmy.utoh.org/3ins4th.html
Phase 2: "A BNF PARSER IN FORTH" Bradford J. Rodriguez
> (This article first appeared in ACM SigFORTH Newsletter vol. 2 no. 2)
https://www.bradrodriguez.com/papers/bnfparse.htm
Phase 3: "Metal to the Desktop in 20,000 LoC"
Using principles from OMeta ( https://en.wikipedia.org/wiki/OMeta ) recapitulate the VPRI STEPS project:
"STEPS Toward the Reinvention of Programming, 2012 Final Report"
> Submitted to the National ScienceFoundation (NSF) October 2012
> (In random order) Yoshiki Ohshima, Dan Amelang,Ted Kaehler, Bert Freudenberg, Aran Lunzer, Alan Kay,Ian Piumarta, Takashi Yamamiya, Alan Borning,Hesam Samimi, Bret Victor, Kim Rose
EDIT: I wonder if including the Linux kernel + C library is just too much. How minimal could one go with this challenge, yet have it still be fun/doable in a reasonable duration? You start with just MS-DOS on the disk? Or a Forth interpreter? Or maybe you start with a blank disk, but you get to twiddle bits one at a time before you first use it, in the vein of the Altair 8800?
EDIT 2: An even more entertaining idea than some sort of 8800-style toggle switch interface: you start with an actual Altair 8800, then get a few "stepping stone" computers that have just enough hardware compatibility that you can transfer data from one to the next. The final computer is a modern PC with a network connection.
For instance, you can't carry hearts/stamina from one file to another in a Breath of the Wild speedrun, or use wrong warping to instantly go to a location saved on an alternate save file.
There are exceptions in certain scenes (in speedruns for Banjo-Kazooie, a glitch is used on another save file to fix the RNG for a quiz section later in the game), but generally, everything has to be done from an empty file/system with no external resources already setup.
Here you have a network connection and you should use it. It's part of the challenge. What counts as an external setup?
Tool Assisted Speedruns (TAS) is a category unto itself. This involves running game on an emulator and making human-impossible precise set of inputs, often disassembling the ROM to find bugs to take advantage of. The Arbitrary Code Execution 'stunt' category includes one where someone programed Super Mario World by picking up items in a precise order (and time) to specify bytes, managing to write tetris and jmp to it.
Competitions are made up, so we can make up whatever point A and point B is, and the rules along the way. Timing going from a Ubuntu ISO to desktop browser with google.com loaded is one A, B pair, but there's so many different possibilities out there!
At work I had all the bandwidth and resources I could use.
So I downloaded all I could during the weekdays and during evenings and weekends I'd just browse manuals and try things on my laptop, in my own little virtual LAN.
That's how you learn, kids.
I did Linux from Scratch back then, for example.
PC games were expensive and except Max Payne, I'd get bored of them very fast.
But the moment I (re)discovered interactive fiction (I seldom played it under an Spectrmum emulator) for the Z-Machine and Nethack from a distro CD, I was hooked.
Need your cursor to be animated but change animations depending on what you're doing? You got it! Find that editing .ini files lacks a certain flair? No problem! Prefer a fuchsia screen of death, or a "fortune" style "safe to turn off your computer" message? I got your back.
Also made a point of reskinning every last pixel. I still get a similar feeling tweaking my Linux environment (albeit stronger focus on productivity these days). Some inspiration in /r/unixporn, maybe you can relive that again ;)
Start with some hardware. If you are lucky, you get a board support package with a Linux kernel. Otherwise you need to write some drivers to talk to the hardware. Progressively get it to the point that it will boot up and get on the network. Then get the application running.
Microcontroller development is even worse. When you don't have any space, you may actually end up writing everything in C from scratch.
But they chose a cheaper ARM CPU without a MMU or hardware floating point. That meant it would not run shared libraries, everything was statically linked. We ran out of space in the Flash, and the project was in crisis. The solution was using a lua interpreter.
These days, I like high level platforms like Nerves: https://www.nerves-project.org/
{ echo -e "GET / HTTP/1.0\r\nHost: ftp.gnu.org\r\n\r" >&3; cat <&3 ; } 3<> /dev/tcp/ftp.gnu.org/80You can browse the wikipedia, read an HN mirror, play IF games and even seek Gutenberg from Bash as I can see by just connecting to the port 70 and doing simple Gopher queries. That's too easy then.
If the shell is the one from Busybox or ash, the fun begins.
The point of the shell example is, that once you have some way to easily open a socket, you can bootstrap a more complete system very quickly. You download a more complete root image from your favorite distribution and override / with that, etc.
OpenBSD's netcat without socks and proxy support can be very barebones and understandable and writable in an hour. With that tool you could fetch busybox in a second.
I assume by "a terrible TCP client" she means a TCP stack, so you don't have a TCP stack yet, so `/dev/tcp` wouldn't exist. Otherwise just opening a socket and sending the request would do the trick. Or maybe that's what she meant by "TCP client"? But writing an editor for that would be overkill I think.
Nice try though :)
If not then that seems like the main part of the work because once you have that then you can download everything else.
Unless it was already in BIOS or some network hardware remote admin Intel thing and there was a way to hack into that to use it. Then you would not have to implement TCP IP.
To me the question is what is the minimal part of TCP /IP that you would need. I guess also you need ethernet if that's not in the C libs.
To cheat maybe your computer has a modem and there is a BBS - simpler protocol.
The exercise states that you have a Linux kernel and there is a network connection. If the kernel does not have TCP, but only offers a raw socket, well, then you have to write down a very simple TCP stack.
But if the kernel does have TCP, the exercise boils down to writing a very simple HTTP client, a very simple DNS resolver and a bare bones XZ decompressor and tar reader. From there I'd grab myself https://alpha.de.repo.voidlinux.org/static/xbps-static-lates... then execute
./xbps-install -S --repository=https://alpha.de.repo.voidlinux.org/current -r / base-system
and call it a day.
Better: busybox build. It already has tar, xz and wget.
You just need to compile a simple HTTP client, or better:
find a gopher mirror. Bare netcat would work against that.
gopher://ftp.icm.edu.pl:70/1/vol/rzm6/busybox/binaries
With NetCat:
echo vol/rzm6/busybox/binaries/1.21.1/ | nc ftp.icm.edu.pl 70
echp vol/rzm6/busybox/binaries/1.21.1/busybox-i586 | nc ftp.icm.edu.pl 70 > busybox
Then ln all the binaries. Or run busybox wget.
Accesign the rest of the files is the same, just redirect the nc command to a file.
If tar is missing, you can just get for sure an static build and compile it. Or try to find an sltar mirror to github ;).
But that busybox has ustar, so look how easy it was with just netcat and Gopher, so writting an nc clone (openbsd's netcat portable version is really easy, altough there are another ones many more times dumbed down) would be the easiest win.
That is, that you can find them in an uncompressed form. If you fees adventurous you can probably coax the compressed data somehow through the bootloader decompressor, or the xz or deflate implementation found in the Linux kernel. Unfortunately these days modules tend to be compressed as well, but it should be possible to convice libdl to open a .ko file. If not you can always mmap it PROT_READ|PROT_EXEC and follow the symbols entries through the TLD yourself.
No nc.
https://github.com/kisom/goat/blob/master/goat.go
Well, JK. A simple, braindead, ugly and fast netcat clone (client only) can be done in C in few functions.
echp vol/rzm6/busybox/binaries/1.21.1/busybox-i586 | nc ftp.icm.edu.pl 70 > busybox
chmod it with a simple C file:
cat > cbox.c << EOF
#include <stdio.h>
#include <sys/stat.h>
int main(){
chmod("/home/crap/busybox", S_IXUSR);
return(0);
}
EOF
cc -o cbox cbox.c
./cbox
./busybox | ./busybox more
Reimplementing echo would be the obvious second thing to do, and later, a barebones cat a la plan9/OpenBSD. Finally the 3rd basic tool would be an ed(1) clone without regex support.
ed(1) can work as a simple "more" like pager, too. Add add readonly flag to argc/argv so it fopens the file with just read permissions and you have the best setting to start. ed(1) is much easier to write than a visual editor.
Any TCP/IP stack related would be hard, but it the libc/kernel has a basic implementation bundled, I'd write a gopher client and I'd declare the problem solved, as I can fetch everything from here.
Gopher is much easier to implement than banging the FTP ports. Also you can do a barebones IRC client with few lines. Nothing too complex, but usable enough.
Or better: write a netcat clone, https://git.2f30.org/openbsd-nc/ connect to gopher, fetch the specs, write a dumb gopher client, (or fetch sacc(1), you can compile it without ncurses by editing the Makefile), connect to gpoherpedia/gutenberg Gopher proxies to fetch all the documentation.
gopher://1436.ninja/1/Project_Gutenberg_in_Gopherspace
gopher://gopherpedia.com
But the netcat clone combined with the ed editor could serve as a basic IRC client with FIFO files, also as a basic gopher client if you don't want to fetch sacc(1). Once you get connected to an IRC channel in order to seek help, among Gopher, you'll have tons of information.
Also it's the most Unix-y way to solve a problem, by far.
Yes, it's still in very wide use. The numbers might be declining as greybeards retire and noobs pick Slack instead, but there's still plenty of us out here.
Incidentally you could take the same approach to some other shell built-ins, like redirection. Instead of `cat foo >outfile`, define a program named '>' and then say `> outfile cat foo`. (Assuming the initial bare-bones shell parses '>' as just another ordinary character, not special.) Use these until you've written a more featureful shell.
It might be interesting to figure out a design for a shell where this decentralized approach works well and does not feel like a kludge -- I imagine you'd have to change some deeper aspects of the OS design to really make it work.
If your shell crashes, same problem. And the shell is a bigger program. This issue seems pretty orthogonal. Again, I was never saying this is a better way to design a shell for everyday use, unless maybe with a lot of complementary design decisions changed to go with it.
> Secondly
Why couldn't you spawn jobs like `& do-the-job` in this style? Admittedly I don't remember much about Unix job handling.
Arch Linux puts responsibility for the install on your shoulders based on your needs and decisions.
In the end, you get a VERY up-to-date installation of linux, without needless bloat, and it stays that way due to rolling updates.
> ... just install Arch Linux to a working desktop ...
How do you do that when you have:
> ... a box that has a couple of hard drives and a working network connection. HD #1 is blank. HD #2 has ... bootloader, kernel, C library and compiler, that sort of thing. There's a network connection of some sort, and that's about it.
> There are no editors and nothing more advanced than 'cat' to read files. You don't have jed, joe, emacs, pico, vi, or ed (eat flaming death). Don't even think about X. telnet, nc, ftp, ncftp, lftp, wget, curl, lynx, links? Luxury! Gone. Perl, Python and Ruby? Nope.
So, how do you install Arch Linux?
It always throws me when someone suggests an exercise, and someone, in reply, says, "Or instead, do this other thing."
I'm oddly reminded of when we were recruiting and asked people to write some code to solve a specific task and bring it to the interview for discussion. Someone said "This spec is obvious nonsense" and proceeded to write a completely different spec, implement that, and get it horribly wrong.
If you read this page:
https://wiki.archlinux.org/index.php/Installation_guide
you might get an idea of what is involved.
I think it would be interesting to see how quickly you could get from there to a useful system, say one where you could download the USB driver from github and compile it. But I definitely don't know enough to do that.
[1] https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
sounds like the beginning of the game A Dark Room
i'd suggest watching lots of YouTube videos before embarking on this in real life though. my "i must be crazy" idea is living in a cabin in the mountains during winter. given the fall to stock up on supplies.
https://www.youroldtimebookstore.com/
> We've done our best to keep Lindsay "alive" by including his original catalog descriptions. Due to the large image size, they are featured on the individual product page. (If viewing a list, simply click the title link or "more info" link for full details...)
> Whether you're a former Lindsay customer or new to these rare publications, Your Old Time Bookstore promises fascinating and educational material for your enjoyment!
Anyway, that's were you get the manuals to rebuild your tech stack from stone age on up.
Thanks for a great read, love ideas like this if for nothing else but to keep one's nerdiness and thirst for obscure trivia alive.
Then of course, once you have the OS you can attempt the classical editor speedrun: https://www.reddit.com/r/speedrun/comments/8rqkzz/vim_exit_s...
After lockdown of course...
I guess if it's a "feel" thing it should be possible to replicate it with lots of tweaking, but I don't think many people who run Linux on laptops use the Apple trackpad much so the overlap between the people who want this and the people who care to write such drivers probably isn't big enough to come up with a Macbook style driver.
For example rest two fingers and press to click, that’s a right click. But rest two fingers and click with the thumb, that’s still a right click, not a three finger click. Same for two finger scrolling. That’s a couple of simple examples but there are a lot of subtle corner cases like that all around the experience which are not just about tuning some values.
And I also cannot put the difference into words, but if you have Ubuntu (even with synaptics drivers) and MacBook side by side, there is a noticeable difference in how they behave and feel but even by having them side-by-side, I can't consciously tell the difference, even if I feel it.
I don't know exactly why this is happening, and there is no in-browser option that can overcome this difference, e.g. disabling smooth scrolling and enabling XInput2 helps but does not overcome the difference. It seems to be something more fundamental in how the drivers work and deliver input to the user interface.
So the quest continues...
There are two modes of operation, what you dislike is the default; the other is called tap-to-click, which doesn’t give you haptic feedback and you can click however fast you want. Opinion is divided on this, with many diehards swearing by the haptic feedback. I prefer tap-to-click.
BUTTON 1 - BUTTON 2 - BUTTON 3
In your situation, you have to tap, lift finger, place finger to move, lift finger, tap, etc. In the other situation, you have to place finger, press lightly, move finger, press lightly, move finger, etc.
Using tap-to-click can't be faster than the other situation.
That said, I use both. Sometimes I just tap, sometimes I press, sometimes I press harder.
Apple with tighter integration delivers the actual touchpad movement data and not a faked mouse event.
Windows 10 has had work done in this area too but not sure the details.
But no matter what, two finger scrolling and zooming won't ever be as smooth and "step free" under Windows/Linux... once experienced, cannot be missed.
That's not true. I'm not sure exactly what's changed but when running Firefox with the Wayland backend I've found that scrolling is continuous.
In Linux, wrists keep triggering touch events as you type. Screens start scrolling, focus goes to random things, and everyone swears. You end up having to hold your hands right over the keyboard in a very unnatural way to avoid accidental mouse interaction.
I’ve had this problem on my current hp laptop that replaced my mbp too. It’s a Linux concepts problem. Linux simply doesn’t cope with hands near the touchpad.
Lots of coders I know use Linux on laptops. They swap recipes for how to disable the touchpad completely.
<sobbing/>
It's a bit better when i disable touch click, but then i have to physically click the touchpad which is harder on the fingers as well !
Then again, I'm pretty sure Synaptics has wrist detection built into the firmware of the trackpad itself. I suppose Apple and Windows do this in software for models that don't support this and that's why it's going wrong.
I'm not saying that people don't use Linux on laptops by the way, I meant that the overlap between people who run Linux and use a MBP isn't very large (because Linux on Apple can be anything from annoying to install to near impossible).
But, as far as I know, Apple still releases the source code for Darwin, right? So shouldn't it be possible to port the trackpad functionality from there? Or did Apple hide the trackpad driver in a closed source blob?
Maybe I'm in the tiny minority here, but I much prefer the way touchpad handling on Linux behaves compared to both Windows and macOS. At least on sway, it feels more 'accurate' than either of those two - you move your finger and the cursor actually goes to where you want it.
> But, as far as I know, Apple still releases the source code for Darwin, right? So shouldn't it be possible to port the trackpad functionality from there?
Unfortunately not! I worked on reverse engineering a driver for the SPI touchpad found in newer (but not too new) Macbooks and based most of it on packet captures from Windows' Event Log [1]
[1] https://github.com/cb22/macbook12-spi-driver/issues/3#issuec...
In KDE: system settings -> input devices -> touchpad -> disable while typing. (this is enabled by default)
In Gnome: I'm not using it, but apparently https://askubuntu.com/questions/923060/how-to-disable-touchp...
I have this problem as well. The Synaptics driver seems to have some palm detection logic but it does nothing. Perhaps my trackpad has no support for it.
> They swap recipes for how to disable the touchpad completely.
Sadly the surface I usually place my laptop on doesn't have space for a mouse...
Enable the option to sleep the touchpad when the user starts typing.
It might sound elitist, but if someone tells me they have a better input interface than one of apple's trackpad, my mind goes somewhere else. I even replaced the mouse at my work with their trackpad.
I remember when I was big at CSGO and wanted to play a few matches on the go one time. I still ranked pretty high, with a TRACKPAD.
I don't think it sounds elitist, but just presumptuous. I don't actually think a TrackPoint is superior in every case, and I think Apple has done a great job for a trackpad, but at the same time I'd hate to go back to a trackpad for general use.
Exactly. I like how Professor Galloway (professor at NYU, investor, podcaster, etc...) puts it - successful businesses create time machines. People will pay large sums of money to gain more time.
I use both Windows and Fedora enthusiastically on desktop machines, but recognize that even high-end Windows laptops have trouble matching my 2012 Macbook in terms of input. Apple has been miles ahead of the competition in this specific regard for years. I would love to use Linux on a laptop, but although the combination of libinput and modern Qt and Gtk are helping here they're still ways off [1].
Many people who have only used Linux and Windows on laptops for years assume that a touchpad is only there as an emergency. That you cannot seriously use a laptop without a peripheral.
On Macbooks, that's simply not the case - I never use a mouse with my Macbook. It's easy and probably deserved to discount Macbooks in other areas (even in terms of e.g. keyboard input, looking at Apple's 2016-2019 lineup), but you don't know how good an input tool a touchpad can be unless you've spent some time familiarizing yourself with a Mac touchpad.
Apple sells desktop versions of the touchpad [2]. It might be difficult to believe, but they do so unironically. I bought one for when I connect my Macbook to a big screen.
[1]: I found that Ubuntu has a better laptop input experience when running in a VMWare Fusion than running natively on a Macbook, despite all hardware working out of the box...
[2]: https://www.apple.com/shop/product/MJ2R2LL/A/magic-trackpad-...
IMO the best way to control Apple devices is KB + mouse + magic trackpad. Mouse is of course superior for precise movement such as highlighting text, but the trackpad itself is worth it just for the gestures.
I never use mice, only trackpads, on Windows laptops and Windows laptops from 2013 with Linux on them, and it's fine. c: And by fine I mean bad, but that's just laptops, as an ontological concept, to me.
Worth noting that there are still usage scenarios where a mouse beats a touchpad (i.e. image editing, pointer centric games), but overall touchpads don't have to be the inferior option if your computer is built for it.
Unfortunately Huawei's reputation is mud these days thanks to the Chinese government. They made pretty nice laptops, though the aesthetics are obviously imitating somebody.
Yes, they do, I'm using one. Aside of haptic feedback which allows it to go really quiet, it's really nothing special - just a regular touchpad. I'm also using the internal one in my Dell XPS - if it was slightly bigger it would be just as good. In the past I've used Lenovo Yoga one and it was just as good either.
I'm using touchpads exclusively on GNU/Linux for years now. It's a myth that Apple touchpads are "magical" - it's just macOS which comes with good defaults, but if you put some effort in it you can get it just as comfortable on GNU/Linux as on macOS (sans continuous gestures, I have to admit that's the one thing I envy them).
> even high-end Windows laptops have trouble matching my 2012 Macbook in terms of input
That's only because vendor drivers on Windows are notoriously bad. My girlfriend is using a mid-2012 13" MBP and its touchpad is rather meh. Not bad, but I've used much better ones. Current Macbook touchpads are better than the 2012 ones though.
Simply put the touchpad on the 16" Mac feels like its from the future, recognition is perfect, multi-finger gestures are consistent and always recorded so you can flip around between workspaces and after a day or two it becomes so ingrained that it gets out the way and you stop even thinking about it, it becomes fluent in a way other touchpads don't.
On a recent Thinkpad with Linux I just use the TrackPoint, I've never gotten the touchpad to be more than merely acceptable.
Frankly I still prefer working on my Thinkpad at home on my stuff but the touchpad on the Mac has ruined every other touchpad I interact with entirely.
Generally I like the Macbook and OSX as someone who hadn't ever touched it til a few months ago is a pleasant OS for development, there isn't anything in there I really hate, it feels like a linux distro with a nice DE/UI mostly.
Oh and I really like iTerm2, that's a really nice piece of software.
But the device was introduced in 2017, and you mention Ubuntu 16. Newer devices require newer drivers.
2. Use Logiops to configure buttons (unfortunately requires compiling it yourself):
https://wiki.archlinux.org/index.php/Logitech_MX_Master#Logi...
The trackpad is part of the reasons (along with macOS, despite its recent slew of bugs) people happily pay more for that others see as “tax”.
Try it out on someone else’s MacBook or a demo machine.
From reading around, most of the distros started deprecating synaptics because it wasn't actively being worked on, didn't work with Wayland, required root for a bunch of stuff unnecessarily etc.
> The xf86-input-evdev driver is in maintenance mode at this point. The last commit was in May 2018 and, since the 2.10.0 release four years ago, there have been a total of 19 commits. It is still shipped in RHEL 8 in order to support "crazy devices" that don't work otherwise. Similarly, xf86-input-synaptics had a 1.9.0 release in 2016 and has had nine commits since. It is effectively dead and all touchpads should be working with libinput at this point. Since libinput took over from xf86-input-synaptics three years ago, no one has stepped up to say they want to continue maintaining it, Hutterer said.
Working software should keep working.
> In the old synaptics driver, we added options whenever something new came up and we tried to make those options generic. This was a big mistake. The driver now has over 70 configuration options resulting in a test matrix with a googolplex of combinations. In other words, it's completely untestable. To make a device work users often have to find the right combination of options from somewhere, write out a root-owned config file and then hope this works. Why do we still think this is acceptable? Even worse: some options are very specific to hardware but still spread in user forum examples like an STD during spring break.
So what causes this difference? Is the Windows driver just better than the Linux driver?
It’s hard to find other details, at least in public...
Imagine if all doctors and surgeons were volunteers; that’s the situation you have now with a lot of OSS.
It's a concept that basically boils down to "people would not be smart enough to understand the code unaided". This is plainly wrong. I speak from experience of diving into some horrible code base.
It also assumes that reproducing the functionality from scratch would be hard. Looking at all the reimplementations of A where A is one of unix, X, web browser, network stack, SQL database and other complex techno, it is also clearly not true.
I also don't see bus factor the same way you do. People can be smart enough to understand the code, but unless someone actually goes and actively takes up code maintenance the project will slowly fade and disappear (for example the synaptics driver that libinput replaced https://github.com/freedesktop/xorg-xf86-input-synaptics/com...).
Sure, but that's always true.
> and even fun - things to do
Never:)
Seems to be like the obvious initial way to up the ante would be to get rid of the compiler. How would you go about bootstrapping your way out if all you had was the Linux kernel, glibc, and the Bourne shell?
You're fully aware that you're describing a complete programming environment and then some, correct?
Bourne's shell (assuming you mean the original, not the GNU 'remake', but GNU bash would practically make this effortless as well although for a different reason) is fantastic for almost any purpose. You can do virtually anything you'd like with it.
You could even go a little further. the printf command should be a built-in with just about any shell, so even lacking the `cat` program, you can output arbitrary data to a file.
Almost seems cheating to just hand-craft an ELF executable from the keyboard, but who's making the rules?
https://github.com/oriansj/stage0
It starts with a system without firmware and an OS, just a <=1KB hex monitor that assembles special hex0 programs. In the next stage it bootstraps a more comfortable assembler. Then it uses this assembler to bootstrap a small C compiler written in assembly. And then it uses this C compiler to compile a C compiler written in C. All the way up to gcc.
I wonder how many of the upper layers have cyclic build dependencies. I know Scala and sbt do but what else?
But maybe also: "Advanced Programming in the UNIX Environnement" https://www.amazon.com/gp/aw/d/B00DB3G8KY/ref=dbs_a_w_dp_b00...
Which is really good
I would probably try to hack myself some sort of Forth-like language and have fun.
Start with an Debian USB stick and finish when you see the output of phpinfo() in a browser
Isn’t cat - > file.txt or echo enough?
AFAIK bash is able to set up tcp connections. Can’t you just download a static compiled editor through this?
Maybe you don’t have bash. So what exactly is the starting point?
If not:
>> echo.c << EOF
#include <stdio.h>
int main(){
while((c = getline()) != EOF){
putchar(c);
}
}
EOF echo "line" >> file
I doubt that the original Unix was written without an editor, using only cat. Of course some earlier interactive system at one point did have to come up without an interactive editor... but still I'd think it's much more likely that the editor was written off-line and fed into the system on punched cards or tape rather than cat'ed from the terminal.
The original post only mentions the network and implicitly the keyboard as possible inputs, but of course the challenge would be much easier if you allowed a DVD, CD, or even floppy drive with drivers (which are part of the kernel). I think pretty much any historical bootstrapping of an interactive OS is much closer to this setting.
For whatever it's worth, Wikipedia (https://en.wikipedia.org/wiki/History_of_Unix) says: "In about a month's time, in August 1969, Thompson had implemented a self-hosting operating system with an assembler, editor and shell, using a GECOS machine for bootstrapping." I'm sure there are more details to be had somewhere.
Also accessible as a file, since everything is a file.
echo "foo" > /dev/tcp/host/port
Heck, a simple while loop over stdin would be enough.
From the K&R book:
#include <stdio.h>
int main(){
int c;
while((c =getchar()) != EOF){
putchar(c);
}
}
The original idea could even be adapted to more than one degree of difficulty... I love the idea, it's, at least, a fascinating concept
Or is the game to do it only with the syscall interface and no library?
:p
One of us! One of us!
There are no editors and nothing more advanced than 'cat' to read files. You don't have jed, joe, emacs, pico, vi, or ed (eat flaming death). Don't even think about X. telnet, nc, ftp, ncftp, lftp, wget, curl, lynx, links? Luxury! Gone. Perl, Python and Ruby? Nope.
There's your situation. What do you do? "
I would swim, do some sunbathing, eat coconuts, do some fishing and generally enjoy the situation. No work, no stress, nobody to bother. :)
(i mean, sure, i'd also do the sunbath and swimming bits, but based on previous experience, most of my time will be spent on the computer :-P)
I found a way out!
The trick would be finding a download that is still served over http.
I mean speedrunning the Linux situation itself. Start with a minimal system and get yourself to the point where you can do something meaningful (like reading cat pictures on Reddit). "
I'd rather do something useful or at least pleasant. I don't have an infinite amount of time and I don't like to waste it.
Should I explain why I don't consider it useful or pleasant?
What on earth are you doing on HN? Close your browser and start solving world hunger!
In fact, I pretty much exclusively use Ubuntu or Ubuntu flavors because in lazy and things mostly work out of the box and if I want, it's still customizable