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?
> 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.
Well yes, I know it can be done, but the point is that it's considerably harder than the original challenge because you can't just output a simple program using the Linux kernel APIs or libc without having a compiler.
You basically just have to know the tricks of inputting binary data through the shell. Learn how the ASCII table works, what the ctrl and shift keys do (setting/unsetting bits 5-7, in particular), and how the Alt key enables the 8-bit.
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?
If you have a shell or standard POSIX tools you'll have printf, which supports hex and octal formatting, and often C modifiers, so you can encode it as one long-ass integer and save keystrokes.
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.
Minimal Linux Live has a nice small script where you see what is being set up. It does include Busybox though, which might already have too many tools.
> We had to bootstrap from nothing originally too.
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.
it had 'ed' the precursor to ex and vi editors. The terminal they used was paper so not quite ready for a visually oriented editor! (https://en.wikipedia.org/wiki/Teletype_Model_33) If you're stuck on a basic system or rescue shell, cat and echo are considerably more straightforward if you don't know how to use ed already.
sorry I was unclear. I assumed those who created ed knew how to use it - but regular people not familiar with ed would tend to use cat and echo when stuck in a broken / bare system.
Of course they knew how to use it. But I don't think they wrote the first lines of ed in ed-on-the-live-system. It is much much more likely that they wrote them offline and imported the code from punched cards or via tape or whatever from another system.
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.
If you have echo and the source code having an ed clone would be very convenient as it would double as a pager.
Also, it would be much faster to edit the files.
Writting a shell is easy, but it's already done (do'h). You could be restricted to a really basic one, with no cd having to reimplenent that yourself. A simple "cd" command taking ARGV as the path would be around 10 lines in C.
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.
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.
Freenode is where I turn when I'm completely stumped by a tough problem. Some helpful person usually points me in the right way quickly. Sometimes I can even point someone in the right direction myself.
It's the default method for technical channels such as programming or OS projects. Please, use IRC with TLS if you can.
Also, Usenet is still good for Slackware and C users, you'll have a high level there. comp.lang.c.moderated and alt.os.linux.slackware are really good. Also, the ones for Interactive Fiction and Nethack, I can't remember the groups. rec.games.roguelike.nethack, maybe.
You're asking on Hacker News if people still use IRC? In this same discussion thread where people are talking about writing Gopher clients?
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.
Note: The “cd” command must be a built-in command in the shell, since it must call chdir(2) inside the shell process; it must affect the “current directory” internal state of the shell process. Therefore, “cd” cannot be a separate external binary.
You could sort of do it via Bernstein chaining. If we call this substitute command 'notcd' then you'd invoke it like `exec notcd /some/path sh` and then continue your work in the subshell.
The shell would then have to also have a mechanism to pass all local state such as command history, local non-exported variables (including shell functions), open file descriptors, currently running jobs, etc. to the subshell.
We're talking about bootstrapping to more usable tools, not about whether this hack fully replaces the standard feature. 'cd' certainly comes before command history, for example.
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.
There are a couple of problems with that design. Firstly, if the program crashes for any reason, you don’t have a shell to fall back on, unless you run the debugger as your shell, like ITS did back in the 1960s. Secondly, you can’t have more than one job running at the same time, or even any suspended jobs. And even ITS (again) has subjobs.
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.
I think an important category has to be: no outside servers designed to help with this speedrunning challenge. Without such a rule, one can get an outside computer to do much of the work. One would merely write a small program that connects to the known IP and pulls bootstrap code straight into memory. (Granted, still a fair piece of work, but without such a rule the finish line for the speedrun would become "establish a TCP connection").
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.
Generally, speedrunning communities (for games and other things) already bar tricks and strats that require setup on an external file/system.
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.
Would this rule also invalidate the OP’s approach of getting to the point where you can download wget, then using that to download other programs? wget, and the things you’d download with it, would live on external systems.
There are different categories for everything. There's getting to the end of the game and defeating the end boss ASAP. For games with a completion percentage, there's speedruns to get to 100% completion rather than just getting to the end. There's categories for not using "warps", and others that allow using "warps" to skip levels.
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!
A basic shell with just forks and execs binaries from $PATH and nothing more. Maybe, just maybe, file redirection. You won't have neither echo(1) or cat(1), you must reimplement them. Echo(1) is damn easy.
Better would be to have a scheduled execution of some bits on the disk, every 5 minutes or so, and you are only allowed to write to disk, not execute anything on your own.
Reminds me of David Beazley's talk about being locked in a hidden vault to analyse 1.5 TBytes of C++ source code. No tools or internet connection, but a Python interpreter.
https://pyvideo.org/pycon-us-2014/discovering-python.html
DavidB is generally awesome, that said I just watched this its kinda of meh, maybe 5-9m of good stuff, if haven't seen his other talks, I'd recommend them first, unless you have particular interest in patent legal suits, and indexing code for basic patterns via a library of functions (grep/glob/etc), ie its basically using stdlib collections w/ files to build a vfs grep/stats lib, w/ py 2.3 while coding on a desert island so to speak. his other talks cover a wide range of subjects, their probably all better imo.
Such an amazing talk !
Someone linked to this on HN a while back, this allowed me to discover David Beazley.
I then got the Python Cookbook, and watched a bunch of other very cool talks. He's an excellent speaker and python wizard!
As someone who can't be bothered to pay the Apple tax, what does the Macbook trackpad do that others don't? My experience with different mouse acceleration configs (Windows, Synaptics, Linux) has only been negative.
You need to experience it to understand just how much more calibrated it is to the human experience, feels natural, like air. :) How about visiting a store that sells macbooks?
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.
If you’re thinking tuning as in artist sensibility and acceleration then you’re quite off, the experience goes way beyond this.
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.
Yeah, I’m not sure why there’s such a massive contingent that admit to having never owned an Apple product (some snarky comment about the Apple tax) and dismiss the hordes of serious engineers who use these products. Can you get 90% of the way there with your favorite flavor of Linux? Yup. Are there some things that Linux does far better? Definitely (looking at you containers). But it’s that 10% sugar that make most (not all) people more productive. But if I can make my expensive engineers more productive by spending a few hundred $ premium on the single most important piece of kit I’m giving them, well that’s insanely good ROI.
Because closed source software is worse for everyone. Regardless of any other feature, being closed source makes Apple products a non-starter for a sizeable subset of the population.
"sizeable subset of the population" is a bit of an overstatement. Most people are fine with running Windows or macOS. There's just a vocal minority that wants open source stuff.
I'm a huge linux fan and run both Ubuntu and Arch Linux on a daily basis, but I used to be on OSX and Apple hardware between something like 2012 -> 2015 before switching back to Ubuntu/Arch. The only thing Apple does better is touchpad input.
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.
One of the main differences is that MacOS has visibly lower latency when scrolling / moving the mouse pointer. This is immediately visible when you scroll the same webpage on Safari/Mac vs Firefox or Chrome on Linux.
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.
Interesting, just tried this, where I compared my laptop (Ubuntu) and desktop (Arch) with my Macbook, and the latency actually seems lower on Linux than OSX, seems OSX has some smoothing that seems to make things look/feel slower. Scrolling is clearly faster on my laptop and desktop than the Macbook (didn't even had to record a video to see the difference), tried Firefox on both Linuxes and Safari/Chrome/Firefox on Macbook with the same result.
I'm switching between mbp and xps15 and honestly couldn't describe the difference. They're slightly different, but I wouldn't call either one "better".
I went to an Apple store to try just this and came away unimpressed. Apart from the much better integration of gestures with the OS, I didn't feel anything special about the touchpad or its acceleration curve. In fact the touchpad was quite annoying to use because there was a kind of block on movement after a click that was far to long, making it difficult to click multiple different things quickly in a row. Overall I preferred my own laptop using libinput at the time :)
> kind of block on movement after a click that was far to long
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.
Tap-to-click is slower though, if I understand correctly. Imagine clicking three adjacent buttons in a row as fast as possible. If you tap each one you have to lift your finger off the trackpad 5 times.
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.
To make stuff worse, Elantech/Synaptics feature-gate their drivers... I have had laptops where I put a trackpad driver from some totally different laptop and suddenly I'd have a lot more gestures.
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.
I'm still using Firefox on XWayland (because of the subtle bugs in the Wayland backend), but you can also get continuous scrolling on X using XInput2 as well (set the environment variable MOZ_USE_XINPUT2=1).
Smooth scrolling isn't impossible, but it does need to be specially implemented. Firefox does so if you set the environment variable MOZ_USE_XINPUT2 to 1. Of course, on Mac OS X, it's built-in to the UI toolkit, so every application has it.
I don’t have a clue about _why_, but I know from using macOS and Linux on mbp that whereas the touchpad basically works in macOS, it totally doesn’t function in Linux! :(
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.
I have exactly the same laptop and don't have any issue with the touchpad either and never really understood what's wrong with non Mac touchpad. Maybe it's just a cheap laptop vs expensive laptop thing than Mac vs Linux.
hear hear, i'm on dell xps 9370 with Ubuntu and I've been having the same issues since the beginning. Yes, I also learned to hover my hands further above the keyboard to compensate. It's not very ergonomic.
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 !
The trackpad in my laptop (Synaptics branded) has never had trouble like that in my experience.
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?
> 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).
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]
At least KDE offers the option to disable the touchpad while typing. I'd expect other desktop environments to do the same. Isn't that what you're looking for?
> 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 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...
> 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. […] Linux simply doesn’t cope with hands near the touchpad.
Enable the option to sleep the touchpad when the user starts typing.
I recently discovered after reinstalling Linux Mint on my Dell XPS (that shipped with Ubuntu) that is not an option "out of the box". On my previous interest I used to have that option. Now I'm not sure where it's gone so I do (very sadly) only have the option to "disable touchpad when mouse is connected." Please help!
Nothing. macOS simply implements touchpad gestures in continuous way as opposed to binary triggers, does it consistently across applications since most of it is handled by toolkit and comes with sane defaults that are harder to accidentally misconfigure than on other systems. Those things contribute to perceived user experience, but there's no real reason other than lack of software polish that it couldn't be like that on other platforms as well. GNU/Linux is slowly getting there, but there's still plenty of work left across toolkits and input stack.
Not when you want speed and precision. the area of touchpad is far greater and it shows when you want to draw something, or move cursor between edges of the screen. that's the same as playing first person shooter on console controller vs the mouse.
My old correctly calibrated trackpoint (on Linux, even) was better at precision movement than any track I’ve used since (including all the major vendors).
Not even talking about the haptic feedback, pressure sensitivity (fun for drawing, handy for quicklook and dozens of other things). Precision? Oh yes. Moving per pixel is bliss.
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.
Most touchpads have just as good precision - well, unless you count really crappy low end ones of course. Haptic feedback is a nice thing and it's the reason why I own a Magic Trackpad 2 (I have even hacked the kernel driver to get it more quiet than what macOS allows), but that's pretty much its only differentiating factor.
> 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 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.
Macbooks do literally nothing, it's macOS that does. And with a bit of effort and understanding of the input stack, you can get it pretty close on GNU/Linux anyway - at least close enough for really comfortable usage. I haven't been using mice for years now and I'm not a Macbook user.
You’re missing the forest for the trees. Nobody saying this can’t be replicated. But Apple does it out of the box, and better than any alternative I’ve tried. That’s why people buy Macs. Time is money.
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.
...but that's a completely different argument to make. I was answering the question about what does the hardware do differently, and the correct answer is: nothing (well, aside of haptic feedback to be exact, but unless you care about silent clicks it's just a gimmick).
Yeah, "nothing" is a really poor term to summarize "Apple made fundamentally superior choices in terms of hardware development, software integration and general OS input architecture in the past 15 years".
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...
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 have a mouse and keyboard attached to my 2015 MBP....and I still reach for that track pad. I really need to replace my mouse with their Magic Trackpad. It's just that good.
>Many people who have only used Linux and Windows on laptops for years assume that a touchpad is only there as an emergency.
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.
Well that's what I'm trying to say :) Touchpads on Windows and Linux are "fine" at best (high end Dells are good enough to get out of the way I've heard) and "terrible" at worst. On Macbooks they're consistently great, and can make it legitimately enjoyable to use a laptop as a, uh, laptop.
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.
My Huawei Matebook actually has an excellent touchpad interface as far as I can tell. The only real drawback is excessive pinch sensitivity, which seems to be application-specific (happens all the time in Firefox, less in Office). Scrolling and selecting are continuous. Minesweeper is still hard to right-click 100% of the time, but that didn't work well on OS X either. In fairness, my most recent Mac was from 2013.
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.
It's been a while since I tried the default setup, but I believe it is set up so mouse buttons are simulated by clicking on the bottom left and bottom right of the touchpad. Additionally the touchpad sometimes causes stray input while your hands are above it typing.
I can answer this a little, for sensible reasons (the team I run at new job was entirely on Macs) I gave in and chose the 16" Macbook Pro over the Thinkpad/Fedora I'd have defaulted to normally (since my personal laptop is a nicely specced T series I still use that for personal stuff at home).
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.
Trying to install Logitech MX Master 2S on Ubuntu 16 and it detects the device on bluetooth but not as a mouse device. So it doesn't move, it's dead. Windows and Mac work just fine. Apparently Logitech can't be bothered to have drivers for Linux or Linux doesn't know Bluetooth well enough to handle all mice.
Use the Unifying receiver, that's what I've been doing for 10 years with multiple devices. It costs like 15 bucks, it's tiny and works flawlessly for any OS/device combo I throw at it, including the Ubuntu 16 + MX Master 2S + K800 that I'm using right now. There's an app called [Solaar](https://github.com/pwr-Solaar/Solaar) that helps with the pairing and such but I don't think it's strictly necessary (can't remember the last time I ran it).
Yes I can imagine it to be annoying for some use cases. My Carbon has, among others, 2 USB-A ports, 2 USB-C ports plus a trackpoint and a pretty good trackpad. My older Thinkpads have more USB-A ports than I'll ever need. So the unifying receivers are only used when sitting at a desk, where they're permanently plugged to USB-C hubs.
I switch regularly between Windows, Linux, and Mac systems with roughly equal time between each. I've never found anything magical about the trackpad, though everyone told me I would. It's a good trackpad, that's about it. Maybe I notice it less because I tend to primarily use the keyboard and avoid the mouse where possible.
What's wrong with the synaptics driver? It's the first thing I installed over stock Ubuntu, to make it even tolerable. Whereas with libinput, after only minutes of use, I noticed I actively avoid using the touchpad, subconsciously bracing for pain and frustration in advance. Is there a reason that libinput is so horrible? I'm not even sure if it's only gnome's/tweak tool's anemic settings dialog, or fundamental lack of kinetic scroll and sensitivity params in libinput itself. It's completely unusable for me.
Meh, libinput works fine for me. I suspect it's pretty hardware-dependent.
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.
> 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.
My laptop has a Synaptics trackpad and came with Windows pre-installed. Trackpad acceleration was really comfortable on Windows. It all changed when I installed Linux. Tried adjusting the Synaptics driver settings but couldn't get it to match the Windows experience.
So what causes this difference? Is the Windows driver just better than the Linux driver?
Haven't had a new laptop in a while, but as far as I'm aware, most touchpads are not Precision Touchpads and instead continue to emulate stuff in the driver without Windows knowing, so you're still at the mercy of the (usually shoddy) driver implementation.
All Windows laptops are now required to have Precision touchpads and for older laptops, you can simply install the precision driver onto them and they work the same way.
That’s because the problem is hard and deep, and most open source contributors work for free and are shallow, working to satisfy their egos and need for intellectual stimulation. Paid expertise is needed here.
Imagine if all doctors and surgeons were volunteers; that’s the situation you have now with a lot of OSS.
Given the large majority of commits to the Linux kernel are done by people employed by companies to work on it, your starting premise couldn't be further from the truth, let alone the conclusions you draw from it.
Given that they said most open source contributors I think they are right. Most contributors are not contributing to the Linux kernel. Most are contributing to (https://githut.info/) JavaScript packages
I think that's being somewhat generous of an interpretation given the thread of the conversation, which is specifically about drivers. For it to be talking about Open Source developers in general would be a serious pivot.
I wonder if any of the commercial distro developers care enough about Linux on the desktop to fix this. Or, does Chromium OS use libinput? If so, then Google could fix this.
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.
Disagree. Learning a codebase from scratch is tricky; it's better if you have someone to teach you. So if the one contributor gets bus'd, then it'll take time (=money) to get up to speed.
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...).
Getting it from a Gopher mirror would be even easier, the protocol is barebones. But bash is cheating, you can write an IRC/FTP/Gopher client in seconds and fetch all the info and documentation from here.
You 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.
I guess that the task is really underspecified (maybe intentionally to have different speed runs). It makes a huge difference whether you have a kernel with a TCP/IP stack, a C compiler, a C library with the socket API, etc.
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.
True. Or as I said, a busybox from a Gopher mirror to an FTP server which mirrors Ibiblio itself. Chmod'ing +x it is dumb easy from C.
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 realized a few years later that this was just an exercise in flexing the fact that I could probably bootstrap my way up from this with the C compiler to write a terrible editor, then write a terrible TCP client, find my way out to ftp.gnu.org, get wget, and keep going from there.
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.
It is unclear to me whether the C libs include TCP.
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.
> It is unclear to me whether the C libs include TCP.
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
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.
> Or just get a static tar and xz static build, they must be somewhere.
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.
Busybox has these in binary form, in either HTTP/FTP/Gopher servers or who knows which other protos. Pick your poison. Once you set a barebones connection to a gopher server from stdin using a little of C socket establishing code, you can just send the commands to fetch the binary, redirect it to a file and chmod(2) +x it with ease.
I'd like to suggest "Linux From Scratch" (http://www.linuxfromscratch.org/lfs/) category. It might be easier for beginners, as it has definite start and finish states and instructions. It would be interesting to do a blind run to see how long it takes and later try a "real" speed run to optimize it as much as possible.
This is how I used to live my life. Sort of. I mean early 2000s when I had left home and moved to a far away city for a job in IT. All I had was a stolen 256M RAM laptop with FreeBSD. No internet and no TV at home because I lived in a shitty apartment building.
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.
Around 1995 I had my own PC but only my dads PC had internet access. Every other day I had half an hour of internet to download stuff. Then lots of time playing around on my PC.
That's how I learned web development in the 2000s. I downloaded stuff at school on floppy disks and took them home to inspect them. I had cool gifs, midi files, html files and I had Home Site 4.0 which had a great documentation about HTML and some basic JS.
Ditto, plus ROMs. SNES/MD/GB ones could be compressed very well, even the N64 ones could be splitted with split(1) and merged with cat.
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.
Sadly, for me in the late 90s, it was learning the ins and outs of how to modify Win95 UI. Turns out a whole lot of those skills were total dead-ends. But I can help you make your Win95 look and feel however you like!
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.
Cool times anyway. Windows 95 brought back the fun I was missing so much since when I reluctantly moved from my beloved Amiga 4000 to an anonymous Pentium PC circa 1994 - I had been programming under Windows 3.11 for a while when Commodore went down the drain.
I recall that custom animated bootup screen was something that had a different variation of the quirky hack in different subversions through 95-98.
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 ;)
I bought the computer, installed Mandrake Linux on it via CD but didn't know how to configure the modem. So I would make notes/print out manuals regarding modem configuration and try them at home daily - until the sweet sweet line noise of connection happened and I was online.
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.
Or have some drinks with EEs and get them to value software development ease of use: things like using top of the line, or at least midrange MCU with enough flash for debug builds, populating debug connectors on EVT builds etc
In one memorable project the hardware guys grudgingly agreed to waste money and give the system enough resources to run Linux.
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.
Are you affiliated in any way to the nerves project? I skimmed the home page and couldn't find out what it is exactly. Is it an elixer framework and related bootstrap code targeting towards running on mmu-less arm cortex m microcontrollers? Or on an embedded liux system? Or is this just a rest endpoint somehow?
I've thought about a variant of this with Baking Pi [1].
That takes you through assembly to the point of having a Raspberry Pi with a minimal terminal (with just an external USB driver the author wrote).
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.
These sound like things that used to be regular part of install/setup on BSD and Linux. It's so much nicer now not having to setup the network, GUI or disks. Nevermind the week of downloading all the floppy images.
> ... 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.
That wasn't clear to me, but in the light of your comment, I see that it's plausible. Thank you.
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.
While installing Arch can be a challenge for a lot of different use-cases, bootstrapping everything from the level described in the article is a little harder.
>" About 15 years ago, I mused about the idea of having a "desert island machine". This is where I'd put someone in a room with a box that has a couple of hard drives and a working network connection. HD #1 is blank. HD #2 has a few scraps of a (Linux) OS on it: 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.
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. :)
It’s fantastic. I was there in 2016. Have visited Greece at least 15 times but Samos is still my favourite. Make sure you rent a bike and drive around the island.
Heh nice, I don’t know if you like sports but climbing is really fun. Each climbing problem is pretty similar to figuring out a programming problem: breaking something down into sub problems, figuring out how to do each one, and then knitting it all together! This is something I like to do for fun :)
>" So here's the pitch: Linux speedruns. By that, I don't mean "speedrunning a game on a Linux box" (like emulation, or something). Nope.
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.
Looking at your comment history I fear this may not be the community for you. Constructive criticism is valued, but negativity and sarcasm bordering on racism are not. Please try to enhance the community rather than detract from it.
Tbh I think its something that's fun once and can be educating, but after doing it once it's mostly just annoying
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
To avoid memorizing certain things to win speed running Linux could be broken down into categories so that it can be a fair comparison. An example would be no memorization or no networking . The current speeedrin community does this already.
283 comments
[ 2.6 ms ] story [ 304 ms ] threadSeems 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.
https://bootstrappable.org/
I wonder how many of the upper layers have cyclic build dependencies. I know Scala and sbt do but what else?
https://github.com/ivandavidov/minimal-linux-script
http://man7.org/linux/man-pages/man2/syscalls.2.html
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:
Or just run nc from a < redirect, but, the shell could restrict that maybe.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.
https://news.ycombinator.com/item?id=10160720
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.
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!
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:
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.
https://iterm2.com/documentation-triggers.html
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...
https://github.com/PixlOne/logiops
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...).
You 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
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
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/
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/
Sure, but that's always true.
> and even fun - things to do
Never:)
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.
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
I would probably try to hack myself some sort of Forth-like language and have fun.