If you live near a makerspace / hackerspace, I would definitely recommend doing projects there. Mine has a weekly electronics projects and repair night with free access. This has two main benefits:
1. Access to a bunch of different equipment without breaking the bank. Want to try out a bunch of different kinds of flux? See what kind of de-soldering tools are good for different tasks? Now you can!
2. Access to expertise and moral support. Trying to do everything by yourself is no fun. A YouTube video can be helpful but it's no substitute for a knowledgeable friend or more experienced mentor.
I recently did an RTC battery substitution on my Framework laptop's mainboard, and I could do it with confidence because I had good tools and people to consult at my makerspace.
I know it's not the same as a functioning PDP-10, but the Byte Shop in Jamaica Plain has a functioning Altair 8800 connected to an ADM-3A dumb terminal, among other working computers from the 1970s and 1980s.
> The disadvantages of coaster brakes are that the pedals cannot be adjusted while standing over the bicycle frame.
Another disadvantage not mentioned in the post is that with coaster brakes the pedals can get trapped by the kickstand. I don't remember the details because this was a long time ago, but I accidentally found myself in a situation where I couldn't pedal forward because the kickstand was in the way, and couldn't pedal backward because the brakes engaged. I don't remember how I fixed it.
You can adjust the pedals while standing, it’s just awkward.
Take your weight off the seat, grab the back of the seat behind you and lift enough so the rear wheel loses traction and then you can push the pedals forward a bit.
> the first example of a "bug" that the author could see, which others are blind to, was search results
The author explicitly says he is using less specific and compelling examples for good reasons:
> I don't want to give any specific examples where it was my job to see how well the thing worked because, even if the internal examples are meant in a constructive, blameless, way, they may not always read that way when re-posted externally, so I'll give a few less interesting and less well supported "random" examples.
I also think it's reasonable to use the term "bug" in a broad or colloquial sense. If a web server is overloaded, that isn't a bug in the strictest sense, but it sure feels like a bug to the person trying to use the website. A search engine is software, and if it fails to surface the most relevant document from its index then I'd say that counts as a bug. Also the author acknowledges this SEO spam issue, e.g. in this quote for the linked post:
> Here's a fun experiment to try. Take an open source project such as yt-dlp and try to find it from a very generic term like "youtube downloader". You won't be able to find it because of all of the content farms that try to rank at the top for that term
One of the things I love about reading a bug report for a bug I've experienced is the feeling of solidarity it gives, a sort of "wow, me too, I thought I was the only one". I immediately recognized this issue, for example:
> when opening a new Google Doc, I used to immediately put the title I wanted into the doc. At some point, maybe ten years ago or so, Google Docs added some kind of delay such that the typing you do into the title box right after you open the doc gets overwritten, so I now have this habit where, after opening a Google Doc, I do something else and then I change the title.
I seriously doubt Google is going to do anything about this behavior, though.
It really is a testament to the power of mindshare and vendor lock-in. Git is GPL-licensed, the format is a de-facto standard, the commits and tags live in an on-disk format, merging and collaboration doesn't require a server, and yet somehow we still managed to end up with a centralized system with GitHub at the center.
This comes up every so often. I think there are good reasons it hasn't caught on. Here's a relevant comment from ten years ago:
> whole point is to be roughly human-readable and using non-printing characters defeats that. You can't even easily enter these things via the command line.
> If we're abandoning human-readability, why even bother with ASCII? Just use a binary format. Has anyone actually used ASCII unit and record separator delimiters successfully? I'd be curious about what advantages they had over a binary format, even just a protobuf or Thrift serialized form. If we want to preserve schemalessness, there's stuff like Sereal.
Here's another one from more than twelve years ago:
> I've done this.
> Everybody hated it. Most text editors don't display anything useful with these characters (either hiding them altogether or showing a useless "uknown" placeholder), and spreadhseet tools don't support the record separator (although they all let you provide a custom entry separator so the "unit" separator can work). Besides the obvious problem that there's no easy way to type the darned things when somebody hand-edits the file.
Yahoo access logs used control characters to separate fields beyond a fixed width field, but it wasn't the record separators. It used ctrl-E to separate fields, which had a one character identifier. Some of the fields had sub-fields which were separated ctrl-F.
I think there is a deeper question: "record separator" and "unit separator" chars are a good idea, but why are they invisible? I agree that in the current form, they are mostly unusable.
What was the idea of the designers how they should be used?
ASCII was created in the 1960s. That's around the time when the industry wasn't really sure if all files were just going to be a stream of bytes that were completely up to programs to interpret, or if it was the OS's responsibility to enforce a database-like structure on all disk-like I/O.
On displaying control characters, as of now, at least VSCode and Sublime Text do show them clearly. VSCode uses Unicode control pictures “␄” with a red background, while Sublime shows plain-text “<EOT>” in grey. You can also copy-paste - the real control character lands on your clipboard. Otherwise the rest of it stands, especially for a non-developer using Notepad or TextEdit.
This is trading off ongoing usability for one-time developer convenience. The example given in the post would also struggle with a large file as it loads the entire contents into memory, while having Python feed you lines allows it to read in chunks. Plenty of accurate, unit-tested CSV parsers exist in every language, it’s fine to use one and be done with it. Tabular data formats are a solved problem.
I'd say a lot of the value in "explain it to me like I'm ten" is just expending more time and effort in explaining something. People of all ages respond to engaging writing and clever analogies, and that tends to accompany the style of writing for a younger or broader audience.
1. Access to a bunch of different equipment without breaking the bank. Want to try out a bunch of different kinds of flux? See what kind of de-soldering tools are good for different tasks? Now you can!
2. Access to expertise and moral support. Trying to do everything by yourself is no fun. A YouTube video can be helpful but it's no substitute for a knowledgeable friend or more experienced mentor.
I recently did an RTC battery substitution on my Framework laptop's mainboard, and I could do it with confidence because I had good tools and people to consult at my makerspace.
reply