My Kid Will Never Hack Linux
blog.jonasoberg.net
blog.jonasoberg.net
I also doubt the engineers at Texas Instruments thought that enabling programs on my TI-84 would spawn my or many others' passion for programming. It was simply coincidence paired with curiosity.
I think curious children of the right mindset will find the opportunity to learn whether we intentionally pursue it or not. In fact, by planning out learning environments for those kids we might be doing them a disservice by structuring their learning towards what WE think is important at a particular moment in time.
But sure, flying car software should be open source.
In the 1980s there was a push for programming as part of the standard curriculum. Whether it was TI's corporate intent, or motivated by satisfying educators' goals, they made programming available on their calculators quite deliberately.
[0] Not really dumb. I was accomplishing my goals, but I had no understanding. It was a combination of rote copying and imitation, and dumb luck.
I am sure you are correct in this statement, but I do not believe in hones in on what the point of the article is. The point is that now that we know people learn in this manner we should do what we can to provide as many learning avenues for future generations. Certainly people will always find avenues, but that doesn't mean that we shouldn't provide as many opportunities that we can.
20 years later... I see people being hired who have no clue how things work under the hood and it makes me very, very, sad.
There are people out there who know how everything works under the hood, and that's great. But they're typically expensive and unavailable.
If I can hire someone within my budget to build something that solves my problem, why is that a bad thing? And if I can build something for someone that gives them value, again, why is that a bad thing? It just sounds like snobbery to me.
There's nothing wrong hiring a mediocre developer (or anything) so long as they aren't tasked with doing something that needs more skill is fine: I've done it myself in the past and will do so in the future. When that something escalates into something that does require more, it can be sad or disappointing to see what the less skilled or less caring person did. Conversely, it can be wonderful to see someone that is a true accomplished craftsman at work, even on banal projects and they should be lauded... if that is snobbish, fine, count me in.
Finally here's a clown that is also a talented musician: https://www.youtube.com/watch?v=O3O1XojnTag
In the professional world, I call this "the person signing my check".
(Edit: ok, ok, there can be superseding criteria as well... mostly in areas where life/safety issues are at play).
As an example, I've encountered bugs with Python libraries that I had to debug using GDB. If I wasn't comfortable with C, my only option would have been to throw my hands up in the air and say "I don't know why it crashes sometimes"
Re: snobbery... maybe? I'm sufficiently self-aware to recognize that I have a lot of pride in the fact that I am comfortable pretty much anywhere in the development stack. Out of high school, I recognized that I would occasionally encounter software problems that appeared to be deeper in the system than I was comfortable with, so... I went and did a dual EE/CS degree.
At this point, I'm happy writing JS (React/Redux are my preference), and I'm happy debugging ARM machine code (I once had a peripheral fail to initialize because the gcc optimizer had reordered code such that I was violating the wait states on the periph). Glitches on the power supply rail? Bring on the oscilloscope. Shit performance in your web app? Let's profile it and see what's up.
So sure, I might be a bit of a snob about this. I put years and years of effort into deeply understanding all of this stuff. You want to hire a guy who knows jQuery and has never manipulated the DOM by hand? Go for it! And when the app is buggy and performs like shit, give me a call and I'll help you untangle the giant ratsnest they made.
That sounds like a balanced ecosystem to me.
On the MVP front, I somewhat agree with you. It all depends on what the product is. I've worked on tech spikes that have involved hardware prototyping, signal processing (both embedded and desktop/mobile), image processing, RF, etc. Those are the types of things where you often can't really "hack it together".
I've also worked on simple, e.g., React Native MVPs. The only advantage I might have over a less skilled developer is that I can generally bang those things out quite quickly; in many cases, faster than the business part is ready for (which is likely just wasteful).
..."like you don't care!"
/word up! //sorry, had to do it...
talk about snobbery ;)
> But they're typically expensive and unavailable.
Because the value of the knowledge is extremely high and the market is flooded with people that can do the job of creation but not solve the problems that arise out of it.
> why is that a bad thing?
TL;DR Short term, that's ok, long term: they have no understanding of what they're truly doing and the consequences as a result. You should accept responsibility for that.
With gatekeeping/a tightly knit community: modding, building a PC, and developing a game becomes an achievement that the kids do. It encourages them to succeed to become apart of the community.
With having training/classes apart of the curriculum: It removes the reward of solving the problem and removes a sense of pride in accomplishment.
I went back to my old high school a few years ago to see the AP Computer Science class and the difference in the students was marked to say the least.
Could you elaborate? I'm not sure by what you mean.
By that time I was old enough to bug my parents enough to get one (Fairchild Channel F)... and things escalated from there to a Vic-20 (and so forth). The first programming I did was to make a game in BASIC that a friend bought and was broken work (simple syntax error). I learned networking (when PC networking meant IPX, BNC connectors, etc) to get the first multiplayer games up and running.
I had no intent to be a professional technologists/developer. It was a means to an end. Much later, after I had entry level tech jobs, I honed the skills and knowledge to really be a professional... honestly, it came pretty easy once I realized I actually kinda liked the field in my mid-20s.
Believe me; I was quite shocked we she came to me out of the blue and was like, "Hey dad; can you come take a look at this? I'm having a problem with Charles and I thought you could help." I was thinking, "Ok, I don't know who Charles is, but I'll listen to her." Turns out she was referring to Charles the web debugging proxy (https://www.charlesproxy.com/documentation/proxying/ssl-prox...) and that she was doing traffic analysis on her games to see if she could hack the data being passed around; not all that much different from Burp which I use for security auditing some of my apps at work.
I hope you had - either after or prior to that point - a heart to heart talk with your daughter about what she was doing.
It's one thing to do that on a game or whatnot - but we all know where that can lead, whether accidentally or deliberately, and we have all heard stories of people (usually guys - but I bet that's going to change in the future) doing something "for the lulz" or "because they were curious" or "just to see what would happen" - and then quickly finding themselves on the dark end of a TLA agent.
Jesus, if there was ever anything that shouldn't be developed like the Linux kernel, it is anything in the air large enough to cause damage if it crashes.
Sure, let's learn from the past: let's make sure there is a monopoly behind flying cars. It will be nice when you will be flying your family on a Sunday afternoon and suddenly you will have to choose between up(?)grading to FlyingCars 10.0 (a.k.a. RustyBikeWithDoors) or paying your house's worth in ransom to get the privilege of landing safely one more time.
The last thing I want is for people to ride around in missiles powered by Windows Embedded or Java SE Embedded, contracted out from Chevy to some software farm in India, with no public oversight except for the fact that Chevy's lawyers can convince the NHTSA that it satisfies whatever harebrained safety checklist the government came up with.
Avionics is a special case in terms of cost, level of automation, homogeneity of products, and level of pilot expertise, which makes the use of some one-off Ada software Boeing wrote 30 years ago much more reasonable.
With any luck, children growing up today won't learn C at all, or at least ONLY for historical understanding. It is an absolute security nightmare. Do we not want the next generation to exclusively use safe languages?
But that is not the point i was making. There are a lot of languages that "have safety". Ada is a prime example as it "has" more "safety" and is really old. And yet nobody talked about Ada before rust came with "safety".
With static analyzers and valgrind even C has enough of memory "safety". (note that Ada has more "safety" then just memory access)
Yes, and in the past twenty-five years these languages have stolen away 90% of developer mindshare from C and C++. The only niches that have held against the onslaught are those that thought that language-enforced memory-safety imposed runtime costs that they couldn't afford, coupled with a complete and total obliviousness to the actual cost of memory-unsafe code--especially over public networks. By the time that the internet (née Internet) became ubiquitous, Ada's name was already mud due to its prolonged standardization process, and it certainly didn't help that there existed no freely-available production-quality implementation until the late 90s. Even if Rust weren't here, Ada just isn't positioned to capture mindshare from the modern crop of developers weaned on dynamic languages, because not only does Ada not provide memory-safe dynamic allocation without a GC (Rust does), but it also doesn't have accessible documentation (all the books that I can find cost money, unlike Rust's free book, and all the standard API documentation that I can find is in PDF format only, unlike Rust's generated HTML docs with built-in search), and it also doesn't provide a package manager (which also kills C and C++ for people who started programming with Ruby/Python/Node), and it doesn't have any of the modern niceties that people expect from languages in this decade (I can't find anything to indicate that Ada supports any kind of closures that don't have to be hacked together manually, and its support for first-class functions seems dubious).
So let me amend my earlier pithy statement: Rust has hype because it's a language with modern amenities that has memory safety with no garbage collector. Nobody's disputing that Ada is safe, but Ada's lack of hype today is not because its safety is deficient, nor is it because programmer's don't care about safety. :P
> With static analyzers and valgrind even C has enough of memory "safety".
Citation needed. :)
Feel free to write yet another page of text about how rust is the most greatest thing that is great and i am wrong.
*Also, though I now contradict myself because they preceded Java, the inspirations for Rust's more formal/statically-checked memory model: C++'s RAII and STL.
Someone has to write (and maintain) the safe languages.
PyPy is written in Python, golang has a compiler made in go, etc. Many others do rely in part on LLVM, but in the "long future" there's no technical reason why a common component like LLVM has to be written in C/C++, who knows, people might switch to something else written in a memory-safe language.
Same with most frameworks I know, regardless of where in the stack.
That's why I believe Java is a bad educational language, and Donald Knuth uses MIX assembly in his books.
You don't need to suffer through yesterday's problems to understand today's.
With Raspberry Pi, Arduino, and lots of other tinkerer platforms out there, the rising generation should have more opportunity than ever to experiment and learn about hardware and make meaningful open-source contributions.
While keeping the codebase of any project simple enough that a novice can pick it up with minimal difficulty is a great ideal, the real world generally limits that and forces some ugly/unpleasant complexity into place.
Summary - we need open-source licenses for flying cars, so our children can tinker with the kernel code, since the current Liunx kernel is too complex for children starting out.
I've always wondered about teaching Linux "history" via hands-on with older hardware and OS (like 2.x kernel building on an older version of Slackware with a 486 or Pentium 90).
I would get nowhere near the experience (and appreciation) of watching you do this on Youtube, compared to the several days experience on real "vintage" hardware.
PS Don't underestimate children. Some will learn C.
It would be a lot easier to do now.
That said, AI is here to stay.
I don't see that. Software neural networks explicitly mimic the neural networks of the human brain. Not saying there aren't functional differences, but the basic structure is there.
> It does not have a capacity for abstract thought
But 'it' does have capacity for unsupervised cluster recognition, and can use the identified clusters to influence processing results. More is likely required, but this seems to be the basic mechanism required for "abstraction."
> that will not come just by investing more in our current technology
I think you are saying that some fundamentals are still missing. I don't disagree, but we seem to have some important building blocks in hand. However, it may be the case that all the fundamentals are now in hand, and it is exactly a process of evolutionary change to yield true AI.
> general intelligence, it will look very different from what we have now
I think this is just the traditional dismissal of "whatever has actually been achieved, that is not AI." At some point this becomes an "AI of the gaps" argument, where the gaps are ever shrinking.
Hacking around on the flying car's infotainment systems, suitably isolated from the rest of the flying car's systems - sure.
That we're not able to fix and maintain equipment that we, as consumers (I'm not a farmer), purchase is downright silly at best and dangerous at worst.
Remapping some engine timings, where the worst thing that could happen is you blow up your engine: mostly fine, although there's a small risk that you cause an accident if that causes you to lose acceleration on the highway. Reading OBD or CAN buses, fine. Writing to the buses: nope nope nope.
And that's just for cars. Flying cars, where many system failures result in an inability of the car to stay in the air: I'd expect this to be thoroughly illegal and heavily prosecuted, because I for one quite like being alive and not underneath a crashed flying car.
Does this stifle innovation? For sure. Does it restrict one's ability to modify the things you own? Definitely. Are aircraft regs sometimes over the top? (For instance, preventing you from updating old built-in gps systems, as came up on HN recently.) Yup. But the regs exist for good reasons.
True story from a part of my life from around the time the author mentions: A Fields Medal winner (this is the highest prize in the field of mathematics, for solving hard open problems that puzzled people for centuries) I have known, by himself read the source of Unix (Sun OS) and learned C. He did it when a young PhD student presented him with code related to problems he discussed with this teacher.
This being said, my 9 year old surprised me this week when he showed me an online computer game that someone abandoned which he fixed by going into the code. A few thousands had played it and given it 4 or 5 stars by the time I saw this working. I had no clue that a kid could do something like this in a rather fancy 3D game. I'd say, lets leave the kids to themselves and try our best to help them keep out of trouble as they go along.
[1] https://en.wikipedia.org/wiki/MINIX_3#Reduce_kernel_size
EDIT: Yes, Linux kernel slowly approaches point when gigabyte of source is a long gone story of a past. I doubt there anybody out there who can say they actually understand the whole of it. And this is probably bad for a lot of reasons, of which being not accessible to a beginner is one of the smallest concern.
EDIT2: Even more so for hardware which is harder to investigate under the hood and probably much less understood - when was the last time when you could claim to have inner mental model of your computer and software on it?
Make a flying car run on the Sinclair micro.
Show me the assembly code.
What's driving the recent trend to put big images at the top of every webpage?
One has to gain fundamental knowledge about operating systems and low-level system programming to tackle problems like kernel development - I do not think it was much easier 25 years ago.
Just my opinion.