2
points
AdamH12113
Joined 2,678 karma
- To me, the valuable comments are the ones that share the writer's expertise and experiences (as opposed to opinions and hypothesizing) or the ones that ask interesting questions. LLMs have no experience and no real expertise, and nobody seems to be posting "I asked an LLM for questions and it said...". Thus, LLM-written comments (whether of the form "I asked ChatGPT..." or not) have no value to me.
I'm not sure a full ban is possible, but LLM-written comments should at least be strongly discouraged.
- When Quake(world) was released, it was common to play games on dial-up modems, where 250+ milliseconds was a normal ping time. If you played on a distant server, you could easily get over 500 milliseconds or even much worse.
- That’s exactly what I’m looking for! Thank you very much!
- Tangential question: Does anyone know of a basic large-signal equation for a triode (or any other vacuum tube type) like the simplified Ebers-Moll equation for BJTs or the square law equations for the linear and saturation regions of a MOSFET? It would really help my understanding, but whenever I google it I only see academic papers, like it's a weird thing to search for.
- I’m interested in alternatives to Raspberry Pis right now and software support is a concern. Do you have any recommendations?
- I don't think this holds up. Historically, memory sizes have increased exponentially, but access times have gotten faster, not slower. And since the access time comes from the memory architecture, you can get 8 GB of RAM or 64 GB of RAM with the same access times. The estimated values in the table are not an especially good fit (30-50% off) and get worse if you adjust the memory sizes.
Theoretically, it still doesn't hold up, at least not for the foreseeable future. PCBs and integrated circuits are basically two-dimensional. Access times are limited by things like trace lengths (at the board level) and parasitics (at the IC level), none of which are defined by volume.
- This is a fantastic summary that's very easy to understand. Thank you very much for writing it!
- What intensity is “high-intensity?” The article doesn’t give a number. Is this something that can be done with a few bright LEDs or do you need a specialized lighting array?
- As an EE who changed majors from CS in college and who has also done a lot of programming, I can see where the author is coming from. But electrical engineering, by its nature, is a low-level field. If CS students spent their first couple years doing algorithms and data structures in assembly, they would also find it difficult!
A key purpose of the repeated exercises in circuit analysis is to build up the student's intuition for how electricity works. Mathematically, it's "simple" -- just systems of (possibly complex) equations and basic diff eq. But for sophomores, all that is still new, and most students don't enjoy going deep into derivations.
Building kits and plugging pre-made modules into microcontroller development boards is fun, but it's not really engineering. You don't hire an EE to plug off-the-shelf components together, you hire an EE to do design work, to make sure everything is going to work under all operating conditions, and to diagnose problems when something goes wrong.
Finally, software is just easier[1] than hardware. Modern software is a mathematical idealization that runs of top of decades of high-level tools and abstractions. That's why it's so cheap and popular!
[1] This does not mean that everything in software development is easy, just that you don't need to deal with physics or chemistry or manufacturing or the procurement of physical goods in order to create new software.
- > Does "career development" just mean "more money"?
No. Career development includes paid training sessions, title promotions (junior -> senior, etc.) opportunities to work on larger projects in more significant roles (resume building), and opportunities to transfer into management, as well as (in some cases) opportunities to publish conference papers and the like. As you get older, this kind of career development becomes more important because it is recognized by people who will hire you.
- “Made from hair” is clickbait — the research is about keratin, a common structural protein.
- From an API designer's standpoint (especially if that API has paying customers), Hyrum's Law is something that has to be taken into account. But from a user's standpoint, it is engineering malpractice, plain and simple. At the very least, relying on quirks of someone else's implementation is a risk that should be understood and accounted for, and no one has any reasonable grounds for complaint if those quirks suddenly change in a new version.
- I use tabs for indentation and spacing for alignment. Tables should be aligned with spaces. A wrapped line can be tabbed up to the start of the previous line and then spaced for alignment.
- This is not even remotely correct. Historically, Microsoft's biggest problem with Office was having to convince people to buy the new versions since the basic feature set was fairly complete. The file format upgrade in 2007 was the only real forced upgrade since you had to have it in order to read other people's files. I have a copy of Office 2010 that still works just fine and can read files produced by up-to-date Microsoft 365 subscriptions.
The same goes for many other pieces of software. People (especially home users) would buy software once and then keep using it until something justified an upgrade. Software subscriptions were historically a B2B thing and IIRC usually came with support packages to help justify the ongoing cost -- especially important in the pre-internet and early internet eras.
- The real money-grab was turning Microsoft Office into a subscription service in the first place. SaaS is a cancer on personal computing.
- That example puts silkscreen reference designators on component pads, which is... not great.
- That’s probably not going to happen. RF simulations are done using extremely expensive special-purpose software, and many components (including basically all digital and mixed-signal components) don’t have simulation models available at all. If they were available, the computing power required to simulate even a medium-size board over any reasonable time scale would be impossible. Simulation is a small-scale thing; you don’t do it for a whole board.
- I wish I had something more specific for you, but my experience is more on the demand-adjacent side (as an EE) rather than directly on the software side. The companies I've worked at have posted on the regular job sites but mainly worked through recruiters. Companies do often post announcements on their LinkedIn, if they have one.
I share your frustration with the fad-driven, cramming-AI-into-everything, rent-seeking model of modern software, and I wish you luck in your search.
- If you're willing to leave Silicon Valley, there are a lot of small companies out there that need one or two or a handful of decent software developers to do useful but non-cutting-edge work. They can't pay Silicon Valley money, obviously, but you get to be a lot closer to other kinds of work, which you might find satisfying in its own way.
- The example is simply wrong, according to other sources. This along with the inconsistent formatting makes me wonder if it was written by an LLM. It's a shame; this seems like an interesting topic.
- Yeah, I actually have a decades-old two-layer board that I need to reproduce and I would love to be able to feed images of it into some sort of tool and have it generate a schematic (or at least a netlist) automatically.
- 2 points
- Unless there’s a leak (and there shouldn’t be) CPAPs are much quieter than you think they are. The only time I even notice mine (Resmed with P10 nasal pillows) is when using it from a battery during a power outage when everything is dead quiet. If you have any kind of background noise (fan hum, AC, air purifier, living near a freeway) you probably won’t even notice it.
- I went looking for the date of this post because I honestly thought it was from the 1990s, when top-posting actually won.
The date is more important than you're giving it credit for. Every creative work has a context and an implicit perspective that comes from that context. This is especially true for nonfiction articles, where the date tells you things like:
* Whether the author is reacting to something that just happened or whether they have the benefit of historical hindsight.
* Where the article fits in the author's overall body of work (including works they haven't written yet!).
* What, if any, recent events may have prompted the author to write the article.
* The prevailing intellectual climate, which carries focuses and blind spots that may be very different from what we have now.
* Whether the article is about something immediately useful or whether it's more likely to be of historical interest.
You can already tell, for instance, that "Thoughts on Software Development (1998)" is going to be talking about very different things than "Thoughts on Software Development (2012)" or "Thoughts on Software Development (2025)". An article like "Better C Programming (2020)" probably contains some useful advice; whereas "Better C Programming (1991)" should be taken with a large grain of salt.
Instead of making readers ask questions like "Why is the person talking about operating system monopolies while saying nothing about LLM model ownership?", it's easier and more helpful to just put the date at the top.
- Needs a (2018) added to the title -- the list of recent posts[1] gives the publication date as 2018-06-13.
Incidentally: Bloggers, please put dates in your actual blog post templates. The date is an important part of the context of any article.
[EDIT: The author of the article has already added the date to their template. Thanks!]
- Amazing that even within the last decade a site as large as LinkedIn could be storing unsalted passwords. How does anyone fail at this in the modern era?
- Are there any similar articles on the state of the rest of the Stack Exchange network? There are many, many other SE sites that have nothing to do programming and are often less amenable to being answered via LLM.
- I think the GP is referring to manually operated elevators, in which a human inside the elevator pulls a lever to tell the elevator when to move. When I was a kid, my dad worked in a building with a semi-automated elevator that had floor buttons and an automatic return to the ground floor, but still had the lever. There was an operator inside on weekdays, but if you came in on the weekend you had to operate the elevator yourself.
The kana are usually written in a table where each row is a vowel and each column is a consonant, like on Wikipedia[1]. Most columns of the table have five characters, each representing the same consonant combined with one of the vowels. For example: か/き/く/け/こ ka/ki/ku/ke/ko, ま/み/む/め/も ma/mi/mu/me/mo. Some columns have "missing" sounds (や/ゆ/よ ya/yu/yo); but what's important for our purposes is that some columns have irregular sounds: さ/し/す/せ/そ sa/shi/su/se/so and た/ち/つ/て/と ta/chi/tsu/te/to. There are no si, ti, or tu sounds in standard Japanese; they have shi, chi, and tsu instead.
Using diacritic markings gets you more consonants. Most of these are made by adding a couple tick marks to the corner of the character, which makes the consonant voiced instead of unvoiced. For example: か ka -> が ga, と to -> ど do, ひ hi -> び bi. But the irregular sounds stay irregular: し shi -> じ ji instead of zi, ち chi -> ぢ ji (again) instead of di, and つ tsu -> づ zu instead of du. (す su -> ず zu gives the same sound but in a regular way.)
You can also combine i-vowel characters with y-consonant characters to get sounds with consonant clusters: き ki + や ya = きゃ kya, み mi + よ yo = みょ myo, etc. The irregular sounds remain irregular: し shi + ゆ yu = しゅ shu (instead of syu), ち chi + や ya = ちゃ cha (instead of tya), じ ji + よ yo = じょ jo (instead of zyo). There's a Reddit post with a nice table showing all the available sounds[2].
Now the problem for romanization is this: Should the romanization reflect the irregular sounds in the spoken language? Or should it reflect the regular groupings of the kana characters? づ and ず might both be pronounced "zu", but they come from different linguistic origins, just as "bear" and "bare" do in English. The Hepburn system uses spellings that match the sounds, while the current standard (Kunrei-shiki) uses spellings that match the kana grouping: し si (instead of shi), ち ti (instead of chi), じ zi (instead of ji), つ tu (instead of tsu), じょ syo (instead of sho), etc.
The Hepburn system tells you how to pronounce the word[3] at the cost of being a lossy encoding. For anyone familiar with the Latin alphabet, that's almost always the better choice, and it's nearly universal in the Western world. Kunrei-shiki does better reflect the underlying structure of the Japanese language and its native writing system, which is probably why the Japanese government preferred it. But anyone who wants to learn the language is going to learn the kana almost immediately (it's just a few hours with flash cards), so IMHO that's pretty small advantage.
I deliberately didn't talk about long vowels, glottal stops, the differences between hiragana and katakana, different pronunciations of ん (n), or how to handle ん (n) followed by a vowel, but if you're curious about Japanese romanization those topics may also be of interest to you. I can try to explain more if anyone's curious.
[1] https://en.wikipedia.org/wiki/File:Kana_chart_1.png [2] https://www.reddit.com/r/LearnJapanese/comments/awzw04/kana_... [3] Most of the consonants are the same as English or close enough and are trivial to write in the Latin alphabet. The big exception is ら/り/る/れ/ろ, normally written ra/ri/ru/re/ro but it's not really the English r sound. See: https://en.wikipedia.org/wiki/Voiced_dental_and_alveolar_tap...