My Kid Will Never Hack Linux(blog.jonasoberg.net)
blog.jonasoberg.net
My Kid Will Never Hack Linux
http://blog.jonasoberg.net/kids-will-never-hack-linux/
19 comments
Actually, I think programming on the TI-84 was deliberately intended to get people interested. Math textbooks from the 1980s and 1990s included BASIC snippets at the end of chapters/sections (in the US). The dialects varied, but porting was a trivial task.
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.
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.
As a completely irrelevant aside, I quickly moved onto Z80 assembly when I was a kid because TI-BASIC was so slow and limited. It was amazing getting sprites drawn at real-time rates.
Same, though I was too dumb[0] to grok what I was doing in high school. It took me until my third CS course in college to finally understand what I was doing at that level of programming.
[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.
[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.
This feels a lot like the good old framework/library debate. Instead of providing everything for the learner in a framework-y way (user must adapt, we call you), it seems better to offer lego blocks instead. Well documented, componentized, reusable things which can act as parts of any new system.
> I don't think the kernel developers 25 years ago had any idea that some kid would be learning C through the code they wrote.
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.
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.
[deleted]
Games. The first computers kids will start to wonder about are the ones they're using to play games, be it a game console, tablet, or PC. Modding comes first, slightly tweaking the game to add a new item, map, or remove some annoying limitation. The truly curious and persistent kids will eventually want to learn how to make their own games. This is where you'll find the next generation of programmers.
Definitely games. This is what got me first hacking when I was a kid. Now as a parent, my oldest daughter (now 13), has been hacking on things for a few years now. First it was with Legos, then Minecraft modding, and most recently she's been trying to hack Movie Star Planet.
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.
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.
> and that she was doing traffic analysis on her games to see if she could hack the data being passed around
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.
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.
This is exactly how I got into writing software. First, I got bored with playing the same scenarios in Command & Conquer over and over. So I learned to make my own. Then I got tired of some of those hacking utilities crashing (all the time!) and said I could do it better myself. So I taught myself to write software.
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.
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.
I hear this argument all the time and it makes no sense to me. If I hire somebody to put my Ikea furniture together, I'm not disappointed to learn they're not a skilled carpenter. When I hire a children's entertainer, I'd be surprised to learn they were an extremely talented musician.
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 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.
It's great, if they can solve the problem! My experience, as a kid who self-taught C after feeling that QBasic was too limiting, is that to debug problems, you often need to go a level or two deeper than the code you're working on.
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.
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's actually the perfect way to be. A startup hiring someone of your level to build an MVP is probably wasting a lot of cash. Most startups will never grow big enough to worry about performance. And if they do, they can afford to pay you to come and in fix their code.
That sounds like a balanced ecosystem to me.
That sounds like a balanced ecosystem to me.
Totally! And that's what some of my gigs have been. "We've got a product, we've found a market, and we need to fix some things about the product that we don't have in-house talent to do"
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).
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).
> my only option would have been to throw my hands up in the air...
..."like you don't care!"
/word up! //sorry, had to do it...
..."like you don't care!"
/word up! //sorry, had to do it...
Why assume that both positions are mutually exclusive?
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
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
Who decides how much skill a given task needs?
At the end of the day whoever it is that is deciding that there is need they will have filled. This can be different from the person that will be the intended beneficiary of the task, or different from the person that will execute or oversee the execution of the task. Of course, this means the adjudication may happen after the fact, but it doesn't change who was initiating the action to make something "a task" and whether or not that person is satisfied with the outcome.
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).
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).
It's all about craftsmanship, and it's about the depth of knowledge. You can hire most people to build a car from a kit. However, you also have to accept blame from getting someone with a shallow understanding of the car when something goes wrong on the car.
> 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.
> 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.
"If I hire somebody to put my Ikea furniture together... "
talk about snobbery ;)
talk about snobbery ;)
I think there is a concern in forcing kids to learn how to program vs gatekeeping and self-taught developers.
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.
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.
As someone with a background in teaching CS at the high school and university level, I've had this sentiment for the last few years but have never articulated it as well as you've just done.
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.
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.
> 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.
Could you elaborate? I'm not sure by what you mean.
This. The whole reason I got into technology was because I needed to know it to make bigger and better games work. I started playing "electronic" games at a very, very early age (4 or 5) and at the time that meant pinball (with rotary dials for score)... then I saw the first video games appear next to my pinball machines... and then the very first home consoles appeared.
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.
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.
Can confirm, caught the programming bug by using Warcraft 3's map editor. It had a really powerful drag'n'drop script editor, which made it very accessible for me to learn about variables, conditionals, and events.
Er... I don't think that's universal, but sure, you'll find some programmers there.
"And we need to adapt our thinking accordingly: we don't need free and open source software and copyleft so that the next generation can hack the Linux kernel; we need it so they can hack a flying car."
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.
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.
Having the same license and freedoms != being developed the same way.
The Linux kernel could do way more damage than any flying car implementation if it failed spectacularly. Besides, it is well established that open source code is safer. If there is anywhere those safety benefits are definitely needed, it would be flying cars.
The cutting edge of formally verified hard-realtime safety-critical software is academic and open source. I would only want to ride in a flying car if its control code was written by public cooperation and was publicly auditable.
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.
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.
> if there was ever ... 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.
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.
Children growing up today won't learn C programming by reading the Linux kernel source code.
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?
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?
Then we need a 'safe' language that has the performance characteristics of C or assembly. Not there yet?
Fortran, Ada, Rust, D, and more.
I feel that without the unreasonable hype behind rust nobody would even mention safety.
Rust has hype because it has safety, not the other way around. :P
Rust has hype because it is mozilla, servo, and mozilla blog posts about it.
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)
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)
> There are a lot of languages that "have safety".
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. :)
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. :)
That's why i said that the hype behind rust is unreasonable. Just look at your post. Is it an objective look at programming ? Or just a lot of words that make rust look like the greatest thing ever ? If you think it is objective, what you wrote that is, then why did you not spend 10min looking at Ada ? Why did you even mention GC, the tired argument as to why "rust is better then Go (note: go has a thing that is more awsome then anything in rust, not that you would care; also go can be used without gc) ? Not that it matters anyway. There is more to programming languages then "features". There is no "perfect" programming language. Rust is most definitely not a replacement for C. And it sucks at "systems programming", whatever that is (for kernel programming, C is definitely a lot better). Just the mere fact that i will not talk about the shortcomings of rust is a clear indication that there is too much hype behind it (you can blame it on the "loud minority", but there is none).
Feel free to write yet another page of text about how rust is the most greatest thing that is great and i am wrong.
Feel free to write yet another page of text about how rust is the most greatest thing that is great and i am wrong.
By all means, please continue to ramble incoherently (who said anything about Go??) while arguing from emotion and failing to refute any of my points. :)
With static analyzers and valgrind even C++ has a lot of memory safety. See Herb Sutter's talks.
It was more the hype behind Java (to a lesser extent, earlier, Lisp) that made memory safety a particularly hot topic/dispute among language evangelists. Although Rust* has made it still more common.
*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.
*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.
Why is the hype unreasonable? Memory safety without GC and at C/C++ speeds? That's half the security bugs of the world solved right there.
Fortran? I admittedly don't know much about it, especially the most recent developments, but my impression was it's perhaps safer than C but otherwise mostly not even as "safe" as idiomatic C++98.
Rust is at least attempting to provide this. I haven't checked the benchmarks, but my understanding is that it's reasonably close for many applications.
If it's significantly slower than equivalent C or C++, it's a bug. Please file them.
Thing is, for understanding why Rust is the way it is, you need to suffer through memory leaks and eg. buffer overflows, segfaults, lack of strict typing, etc.
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.
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.
That's like saying, "to understand why the automobile is valuable, you need to suffer through a horse and carriage".
You don't need to suffer through yesterday's problems to understand today's.
You don't need to suffer through yesterday's problems to understand today's.
Fair point. But I know that for me knowledge of machine-level or at least C-level code is requisite know-how to comfortably build abstractions on. I'd have a problem starting in the middle of a stack at a boundary someone else has drawn for me, and which at times seems arbitrary to me (speaking in terms of general knowledge scope, not about work on a particular project). I frankly don't get how this' generations young developers can cope with this kind of ignorance and unknown territory in their stack (but I admire or pitty them for it rather than looking down to them).
I don't think it's about suffering yesterday's problems to understand today's. Learning to program in C made me a better programmer because I had to watch out for memory, etc. I think a better analogy would be how even with modern animation software, great animators still recommend being able to draw well with pencil and paper ("lower level", slower) to develop a sense for the nuances of animation.
[deleted]
> Do we not want the next generation to exclusively use safe languages?
Someone has to write (and maintain) the safe languages.
Someone has to write (and maintain) the safe languages.
You can easily write the compilers/interpreters/other tooling in high level, memory safe languages. Not all, but quite a few of those safe languages have their tooling built in the same language
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.
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.
Counterexample: Rust compiler is written in Rust.
Doesn't Rust compilation rely on LLVM for all the actual compilation from IR to machine code?
For now it does, but there's an upcoming experimental alternative backend written in Rust. Furthermore, there's no reason that LLVM has to be written in C++, it was just the best choice available when LLVM got started 15 years ago. Suffice to say, there are higher priorities for the Rust project than porting LLVM. :P
Yes, but there is a research project here that replaces LLVM for codegen: https://github.com/stoklund/cretonne
Not like it requires C to implement a new language.
This is a remarkably common belief and it bugs me to no end. I don't know why, but many people have developed this conviction that C is required for computers to work, that that's the baseline of computation. This comes from both novices and experts. I haven't figured it out.
The C Abstract Machine looks like a generic machine based on the Von Neumann architecture, so it "feels" like it should be fundamental. Add in some sunk-cost fallacy, and a lot of people end up with the belief that C is fundamental to computing, despite the existence of systems that do not use any C.
There are plenty of small, toy-level kernels out there for people to cut their teeth on. Linux used to be this way, now it's more grown up. There's nothing wrong with that, no reason people have to specifically target the Linux kernel.
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.
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.
Meh.
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).
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).
Well sure but nowadays you can do that with virtual boxes and whatnot. Much more convenient. Remember that build your own linux post from not to long ago? Following those instructions I not only built linux from scratch with custom compiled libc and busybox. Sure I did that when I was 16 or 17, but in those days the same work would have taken me days not hours. And if you want to teach people, you can easily record what is going on on the screen. So you definitely you should do that but with modern tooling. Both for your own sanity and for better outreach!
What I am trying to get at, your days spent learning what took you hours today, would not have been possible without the foundation you created during those several days as a teenager.
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.
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.
You can help them understand by writing and submitting documentation. Let's be honest, the linux kernel documentation mostly sucks and (more commonly) doesn't exist.
PS Don't underestimate children. Some will learn C.
PS Don't underestimate children. Some will learn C.
I taught myself C when I was 14.
This was back in the late 80's.
It would be a lot easier to do now.
It would be a lot easier to do now.
Definitely. HN probably doesn't think about it much, but go to high school hackathons or take a look at Github -- there are a bunch of teenagers around who have learned pretty incredible amounts of programming. Here's an example of one who learner C and wrote his own kernel, among other things: https://github.com/GruntTheDivine?tab=repositories
Your children will probably be learning AI, ML and neural networks instead of the lower level stuffs which their dads completed working on.
[deleted]
That bubble's gonna pop eventually, I don't foresee it staying around for 10+ more years.
What do you think will stop artificial intelligence from becoming a closer and closer approximation of human intelligence?
The fact that our current technology (neural networks, genetic algorithms, etc.) is fundamentally different from how the human brain works. It does not have a capacity for abstract thought, emotion, creativity, etc. which are all essential to human intelligence. They can do specialized task, but we are many years away from general intelligence, and that will not come just by investing more in our current technology. If we "invent" general intelligence, it will look very different from what we have now in terms of "AI".
> our current technology (neural networks, genetic algorithms, etc.) is fundamentally different from how the human brain works.
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.
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.
Your question as asked has lots of reasonable answers, such as the fact humans aren't all that intelligent on average, and certainly not some asymptotic limit we're aiming for.
That said, AI is here to stay.
That said, AI is here to stay.
I'm sure that it's here to stay, only that it will become much less valuable in the near future. Just like how the .com bubble popping didn't cause the Internet to disappear, the ML bubble popping will not cause machine learning to go away. Instead, it will make it something ubiquitous that gets used with very little thought, removing most of the specialized job market for it.
"humans aren't all that intelligent on average"
Who even needs a kernel? First start learning to program on the bare metal, like us oldsters used to do. The Arduino environment is wonderful for this. Dirt cheap, easy to get started by copy/paste code, and the environment is full C++. I have thousands of lines of code running on Arduinos and none of it took skills that a 12 year old couldn't master.
While I like the sentiment - hacking a flying car seems like a terrible example! Regulations on any flying passenger transport don't seem like they would, or should, ever allow this to happen.
Hacking around on the flying car's infotainment systems, suitably isolated from the rest of the flying car's systems - sure.
Hacking around on the flying car's infotainment systems, suitably isolated from the rest of the flying car's systems - sure.
I think a better argument, with the same sentiment, is allowing farmers to fix their own equipment. https://www.theguardian.com/environment/2017/mar/06/nebraska...
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.
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.
People have been doing that to cars for years, and if you have an object weighing a ton or so moving at 50 km/h, we're dealing with 16 Mega Joule already so hacking cars should not be that different. If you are not able to do anything significantly bad, you will probably not be able to do anything remotely useful either.
I guess it depends what you're doing.
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.
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.
I cannot think of anything worse than flying cars. The noise, visual pollution, lack of privacy, waste of energy and sheer lack of imagination of finding a new way to live on this planet makes me grind my teeth. I hope they are easily hackable so that they can all be programmed to stay on the ground for ever.
We've move up the stack. Kernels are a lot more developed than they were when the author was a kid and in the present day there's a lot less to be gained by writing your own / hacking on an existing one. His kid will hack on something else even more interesting higher up the stack.
>When I was a teenager, around 15-16 years old, I started to learn C programming by reading the source code for the Linux kernel.
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.
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.
So? Perhaps his kid will hkac MINIX. According to wiki page[1], there is only 6000 lines in its kernel. Not everybody has to start by cakhing a monolith. As long as there are smaller things.
[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?
[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?
My kid will never learn Z80 assembler on a Sinclair micro.
Probably not unless they are interested historians, but who can predict? Hardware of tomorrow may have open quantum cores that simulate the Sinclair micro down to a microscopic scale. The future internet archive may include tooling to port their designs to Z80 assembler on the fly.
Make a flying car run on the Sinclair micro.
Show me the assembly code.
Content aside, it feels odd that the banner image is bigger than the whole article.
What's driving the recent trend to put big images at the top of every webpage?
What's driving the recent trend to put big images at the top of every webpage?
Although the kernel is obviously more complex, I think there was never a time were people started programming in C with the Linux kernel. Most people start with "normal" user-space C before going into the kernel.
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.
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.
I think a Raspberry Pi is a very suitable beginning device, and even runs Linux. A lot of documentation and projects and a lot of possibilities both hardware and software wise.
Just my opinion.
Just my opinion.
well said pro AGPL license apology.
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.