Airplane! was a shot for shot remake of Zero Hour!. Almost. Star Wars had many shot for shot "borrowings" of extended sequences from The Dam Busters.
I own a book[1] called "The Dam Busters", about allies breaking German dams - also had a C64 game that was the same theme. Is the movie the same thing? (Allies breaking three German dams).
[1]Back when I was but a child (and the earth had only just cooled) schools used to give out awards to the pupil with the highest average mark in the grade for the year. These awards were usually books, and The Dam Busters was a book given to me as part of these awards. I had not thought about it in over 30 years until you mentioned it.
And get rid of zero-delimited strings in all APIs. Horribly dangerous.
bash is not all that great a scripting language. We have many better options to choose from. Demote it from its position at the heart of everything put.. oh, maybe Python 3 in its place.
You can already use python as your scripting language. Why force the rest of the world to use it? Let people choose it based on its own merits.
VFS... it's useful to have the notion of a volume root for backups and mirroring and mounting and such. I'll give Windows this, except I'd prefer volume names to drive letters. Like old school DEC stuff.
Trash/recycle implemented at system level. Automatic deleting of the oldest trashed files when disk space is needed.
So go ahead and do both of those things. A system of soft-linking and mount points coupled to a cron job would give you this. You can even do the scripting in python if you want.
I'd also like to see all configuration done via sqlite. Use a sqlite editor instead of a text editor. It'll be easier to search and to figure things out. XML would be my second choice.
Storing configs in a binary file? Don't you already have that with systemd? What would another binary registry file buy you?
A/tmp file system that is never written to disk at all unless necessary. Kind of a cache in reverse.
Why would I want to use up expensive RAM for temporary files? If you want to you can go ahead and set up a RAMDisk and mount/tmp on that.
Set user and group on folders instead of files, so you can more easily be assured of what has access to what based on path spec?
I thought you could already set user/groups on folders.
I would say most of the time I achieve my goal well within 29 months at which point the project is ready to be handed to over to people who would have difficulty putting it together, but have enough skills to ride a mature project through the rest of its life time.
Maybe it works differently in development. I can say with a great deal of certainty that if you're talking about development then you're talking nonsense. It is orders of magnitude easier to develop something new than to maintain someone else's mess.
All (experienced) devs have seen the following movie:
Hotshot devs create something new as per management's instructions. They take every shortcut in the book to produce a product in record time - spaghetti code, no documents, no comments, 12k line functions, no local variables (all globals), multiple buffer overruns... and almost fully untested. They sing their own praises to management emphasising how quickly they work, because "we're that good".
Of course it's a fucking mess that crashes anytime a user does something out of the ordinary, so it has to be maintained. A maintenance team is assigned (usually just a lone developer without the spine to refuse) and get told to "add this small feature". It takes them a few days just to figure out which globals in a 17-level deep nested if-then-else construct may impact on the behaviour, so it takes them more than a few days to implement the feature, no matter how small.
Of course, the original asshole devs use this metric to make themselves look good to management: "Look, we created the the thing and we only took so long - these other devs that maintain it are so poorly skilled that it takes a week just to ADD to it. We're obviously much more skilled." This false metric gets used by these asshole devs to justify why *they* should be creating the next new product requested from management.
And thus the cycle repeats.
Make no mistake - if you do the "create new product" bits and not the "maintain existing product" bits, you are doing the easy bits!.
The creator of bugs is less-skilled than the fixer of bugs. We understand that it makes you look good to management to say "see how quickly I can create", but it takes less skill than "I've got to read and understand this mess, and only then will I be able to fix it."
Trust me, you are the less-skilled, not the more-skilled. Don't talk down about people who are cleaning up your mess - they're essentially wiping your ass after you've taken a dump. If you were any good at all, you'd wipe your own ass.
Not offensive, but short-sighted. If I found stupid and short-sighted comments offensive, I couldn't stand Slashdot.
If the main reason is women raising kids, we've got a problem and the discussion is not over.
It isn't, there isn't and it is. The last time I looked fewer men with custody received maintenance than women with custody (about a tenth of the numbers as compared to women with custody), and the maintenance they received was on average a third of that awarded to women.
We disproportionately reward women who raise kids compared to men who raise kids.
That work is vital for the future of society,
So is collecting garbage properly, but we don't reward it much. This is because of the level of skill involved. On average, a higher level of skill demands a higher reward. "Raising children" is a skill level that is bottom of the barrel, even lower than collecting and disposing of garbage.
The actual problem is people are are bad at math and science are comparing "female with custody" to "males without custody" and ignoring the child support payments as income/lack of income.
You can't use "males without children" as a control for "single mothers with custody". Once you compare like with like, females tend to pull ahead in terms of income received.
But there's no sense crying
over every mistake.
You just keep on trying
'til you run out of cake.
And the science gets done.
And you make a neat gun
for the people who are still alive.
(Go ahead and mod me offtopic, and I shall become more powerful than you can possibly imagine)
Better to say "I've done this in the past, and have a working version" or "I've got a demo at home".
Stupid - if it is already done by yourself and exists (even prior to you joining the company), then the company will simply claim it. Fighting for ownership of a product, even with overwhelming evidence on your side, will cost more money that you make in a year. Add to this the fact that you'll be unemployed while fighting for ownership.
Don't be stupid, be smart - if you have already created a product (or parts of one) then don't offer it to your company (don't even let them know it exists), simply leave and start your own company.
Fors is still claiming it plans to hold to that 5 year timeframe (2021), and Nissan is aiming for 2020. I think you're underestimating the amount of work the big manufacturers and parts suppliers have been putting into this.
In some cases the amount of effort put into something is irrelevant.
For example, the amount of work put into solving the halting problem doesn't mean that a solution will be found (or that it exists). In this case quite a lot of folk are working on the assumption that SDC's can be done without general AI. Personally I doubt it, but even my most optimistic predictions for AI smart enough to drive a car in the conditions that humans do place it several decades out (general purpose AI).
Brute-forcing a problem to find a solution is easy. SDC's need more than that.
In my opinion, the reason why Apple and Google have pulled out is not that the technology does not work, but that it is not yet demonstrably sufficiently reliable, and that cheap sensors that make the technology both feasible and economic are not out yet.
The sensors are the easy part. The hardware is a solved problem. It's the software that is the problem. With hardware you can look at something that is 99% complete and make a pretty good guess about what to put into the missing 1% to solve the problem. Software that is 99% there may never be 100%, not matter what you do.
Some problems are not solvable even with all the computing power in the world. Those tend to be the software problems (AKA the math problems). SDC's have already solved the hardware problem for the last two decades. They haven't made much progress solving the software problems. At this point there is no indication that the software problem is solvable within our lifetime.
Over a year ago, when schmucks were saying that SDC's were just around the corner (five years time) I pointed out that SDC's were mostly at the same level in the mid-nineties as they are now, with improvements barely incremental.
Of course, I got told that things have changed, that large strides have been made and that revolutionary improvements have appeared for SDC. Bull, of course.
Since the mid-nineties the hardware used for SDC has increased in computational power by perhaps four orders of magnitude (1000000%) while the SDC capability (how often a human has to intervene to correct is one measure) has increased by perhaps 2%. This is not a sign of improvement.
It doesn't matter how low the accident rate for SDC's go if they do not go to absolute zero.
If you, the customer, want to allow the manufacturer to dodge the liability in their product, then fine - go ahead and do it. However, if that product then harms me on a public road, the manufacturer doesn't get to claim "Well, our customer agreed to the EULA".
The "low accident rate makes it moot" only makes it moot for those who accept it - i.e. the SDC customer. Unfortunately for the manufacturer, any defect in their product that harms a third party means that the manufacturer is still liable.
That's the current law. I do not foresee any changes to it to accomodate self-driving cars. In fact, I would vigourously oppose any law that prevents me from taking a manufacturer to task for an error made in the decision-making in its product.
Did you even read my post? It was not about the article.
The headline is beyond stupid.
If you wish to reply to something other than what I wrote then feel free, but don't be critical of me for it.
You make judgements about all articles based on clickbait headlines?
No, I wrote a judgement about the headline based upon the headline and very clearly wrote that I was doing so.
This does not look like a critique of the headline:
Beyond stupid - the people in charge of children and livestock are found culpable so why let people in charge of something with less brains than either off?
When we've got an A.I. like the fictional ones of HAL or Colossus it's time to revise the rules, but finding a lookup table culpable? Beyond stupid.
In what way is that making the self driving car liable?
It's making the manufacturer liable. Seriously, did you even RTFA?
Where the manufacturer is found to be liable, the insurer will be able to pursue a subrogated claim against the manufacturer under existing common law and product liability arrangements and recover their costs from the manufacturer.
Now do you understand?
The headline is beyond stupid.
Then to avoid misconceptions you should have maybe read the article. Even the summary makes the point that if the passenger is not liable then the manufacturer is.
I note that initially you didn't specifically call out the headline as being stupid, you just generally called the story stupid.
The machine itself should IMHO not liable whether the manufacturer, programmer, passenger or mapmaker is or not. If someone fucks up the lookup table that people call an A.I. then that person or their employer should be liable instead of some stupid fiction about a car being able to make choices and found to be responsible.
That fiction is only in the headline. The article *and* the summary clarifies things. You make judgements about all articles based on clickbait headlines?
Beyond stupid - the people in charge of children and livestock are found culpable so why let people in charge of something with less brains than either off?
The people in charge of the SDC is the manufacturer, not the passenger. The manufacturer determines how the car drives. The passenger only determines the destination. Do you also think that you are liable if you're in a taxi that gets involved in an accident?
What I mean is that eventually, when the bugs have been worked out and only automated cars are allowed to use most of the lanes on the interstate and the accident rate stabilizes (hopefully near zero) then the burden will be shifted from the automakers to the customers, who will pay for it along with the rest of their mandatory liability insurance. The insurers aren't going to deal with insuring vehicles individually until the risk is reasonably estimable.
Why should the customer *ever* be liable for a malfunctioning car? If it is supposed to self-drive and it doesn't, then that's not my fault, it's the fault of the manufacturer.
Car makers are selling Autopilot knowing full well that the people behind the wheel will be texting/surfing on their phones or in car entertainment systems.
Car makers are selling cars without Autopilot knowing full well that the people behind the wheel will be texting/surfing on their phones or in car entertainment systems.
And the manufacturer then doesn't have any liability. It sounds like you are in agreement with parent.
I agree, documentation of protocols needs to be improved; however, it's hard to document everything you did for a paper when the journal doesn't give you very many words at all to actually explain what you did, and many don't support video sections for online papers.
Video is almost always less information-dense than text. Why would you want to spend ten minutes watching something that can be read in 60 seconds?
Dereferencing the virtual address 0x72 is guaranteed to crash an application when the OS is designed never to map the first (usually 4K) addresses. Accessing that memory causes a page fault, the OS searches the page table for the corresponding page mapping, fails to find a valid mapping, so you get a segmentation fault.
This has nothing to do with C though. C says the behavior is "undefined" if you set a pointer to a location that is not used to store a C object.
We've already agreed that it's undefined behaviour. What we're arguing are the circumstances that this particular invocation of UB would result in a crash. Just because something is UB doesn't mean that it consistently crashes at the point of UB.
Oh, it can. It just won't do it reliably. Setting a string pointer to 0x72 will certainly do.
It can. It might not though. It depends, actually, on whether it is ever deferenced or not. The original *s = 'H' can crash without ever needing any more derefencing. Your correction can (not 'will', but 'can') crash only if it is dereferenced.
Setting it is not enough, you have to dereference it as well. Although now that I think about it, depending on the platform, simply dereferencing it may still not be enough.
For example, I just tried it now, verbatim, in the OS kernel I hobby-developed and it worked just fine reading from it. Of course, it returned some random address stored in the interrupt vector table, but it did not crash!
I can also write to it too - I've not yet filled in the IVT so no interrupt number is using those numbers... yet! The OS is probably going to use int-0x80 and storing 12 bytes at 0x72 will not reliably overwrite address 0x80. At the current alignment it certainly will not. A single character more will take the total to 13 + alignment padding = 16 bytes total, which is 0x72. A bad jump here will probably reboot, which we can safely judge to be a crash.
I guess the Russians flooding the internet with fake news in order to delegitimize every single news organization is not hacking? I'm not convinced there was voting machine hacking, but the Russians definitely engaged in social hacking in a concerted effort to boost Trump.
Lemme guess, you hate Woodward and Bernstein too right? They influenced presidential politics the same way you think those 'commie bastards' influenced the election.
Slashdot Mirror
Airplane! was a shot for shot remake of Zero Hour!. Almost. Star Wars had many shot for shot "borrowings" of extended sequences from The Dam Busters.
I own a book[1] called "The Dam Busters", about allies breaking German dams - also had a C64 game that was the same theme. Is the movie the same thing? (Allies breaking three German dams).
[1]Back when I was but a child (and the earth had only just cooled) schools used to give out awards to the pupil with the highest average mark in the grade for the year. These awards were usually books, and The Dam Busters was a book given to me as part of these awards. I had not thought about it in over 30 years until you mentioned it.
Must do wonders for your self-esteem to know that you're only getting some because of your bank balance. lol. Each to their own I guess.
He's aware. Most men aren't aware that they are being used. You sound bitter that he knows what the deal is.
And get rid of zero-delimited strings in all APIs. Horribly dangerous. bash is not all that great a scripting language. We have many better options to choose from. Demote it from its position at the heart of everything put.. oh, maybe Python 3 in its place.
You can already use python as your scripting language. Why force the rest of the world to use it? Let people choose it based on its own merits.
VFS... it's useful to have the notion of a volume root for backups and mirroring and mounting and such. I'll give Windows this, except I'd prefer volume names to drive letters. Like old school DEC stuff. Trash/recycle implemented at system level. Automatic deleting of the oldest trashed files when disk space is needed.
So go ahead and do both of those things. A system of soft-linking and mount points coupled to a cron job would give you this. You can even do the scripting in python if you want.
I'd also like to see all configuration done via sqlite. Use a sqlite editor instead of a text editor. It'll be easier to search and to figure things out. XML would be my second choice.
Storing configs in a binary file? Don't you already have that with systemd? What would another binary registry file buy you?
A /tmp file system that is never written to disk at all unless necessary. Kind of a cache in reverse.
Why would I want to use up expensive RAM for temporary files? If you want to you can go ahead and set up a RAMDisk and mount /tmp on that.
Set user and group on folders instead of files, so you can more easily be assured of what has access to what based on path spec?
I thought you could already set user/groups on folders.
You also complain about being paid bottom dollar while living in the Valley, so either he's right or you were paid starvation wages before.
With my current contract in government IT, I got three job titles: I'm a computer engineer doing system admin tasks at a desktop tech pay rate.
Yes, I'm getting paid bottom dollar. No, I'm not starving at $50K+ per year.
I've got news for you - if you're getting paid desktop tech pay, you're doing desktop tech work.
I would say most of the time I achieve my goal well within 29 months at which point the project is ready to be handed to over to people who would have difficulty putting it together, but have enough skills to ride a mature project through the rest of its life time.
Maybe it works differently in development. I can say with a great deal of certainty that if you're talking about development then you're talking nonsense. It is orders of magnitude easier to develop something new than to maintain someone else's mess.
All (experienced) devs have seen the following movie:
Hotshot devs create something new as per management's instructions. They take every shortcut in the book to produce a product in record time - spaghetti code, no documents, no comments, 12k line functions, no local variables (all globals), multiple buffer overruns ... and almost fully untested. They sing their own praises to management emphasising how quickly they work, because "we're that good".
Of course it's a fucking mess that crashes anytime a user does something out of the ordinary, so it has to be maintained. A maintenance team is assigned (usually just a lone developer without the spine to refuse) and get told to "add this small feature". It takes them a few days just to figure out which globals in a 17-level deep nested if-then-else construct may impact on the behaviour, so it takes them more than a few days to implement the feature, no matter how small.
Of course, the original asshole devs use this metric to make themselves look good to management: "Look, we created the the thing and we only took so long - these other devs that maintain it are so poorly skilled that it takes a week just to ADD to it. We're obviously much more skilled." This false metric gets used by these asshole devs to justify why *they* should be creating the next new product requested from management.
And thus the cycle repeats.
Make no mistake - if you do the "create new product" bits and not the "maintain existing product" bits, you are doing the easy bits!.
The creator of bugs is less-skilled than the fixer of bugs. We understand that it makes you look good to management to say "see how quickly I can create", but it takes less skill than "I've got to read and understand this mess, and only then will I be able to fix it."
Trust me, you are the less-skilled, not the more-skilled. Don't talk down about people who are cleaning up your mess - they're essentially wiping your ass after you've taken a dump. If you were any good at all, you'd wipe your own ass.
Not offensive, but short-sighted. If I found stupid and short-sighted comments offensive, I couldn't stand Slashdot.
If the main reason is women raising kids, we've got a problem and the discussion is not over.
It isn't, there isn't and it is. The last time I looked fewer men with custody received maintenance than women with custody (about a tenth of the numbers as compared to women with custody), and the maintenance they received was on average a third of that awarded to women.
We disproportionately reward women who raise kids compared to men who raise kids.
That work is vital for the future of society,
So is collecting garbage properly, but we don't reward it much. This is because of the level of skill involved. On average, a higher level of skill demands a higher reward. "Raising children" is a skill level that is bottom of the barrel, even lower than collecting and disposing of garbage.
The actual problem is people are are bad at math and science are comparing "female with custody" to "males without custody" and ignoring the child support payments as income/lack of income.
You can't use "males without children" as a control for "single mothers with custody". Once you compare like with like, females tend to pull ahead in terms of income received.
so their science could get done,
But there's no sense crying
over every mistake.
You just keep on trying
'til you run out of cake.
And the science gets done.
And you make a neat gun
for the people who are still alive.
(Go ahead and mod me offtopic, and I shall become more powerful than you can possibly imagine)
We've got some smart ass border agents.
you've missed a word. I took the liberty of fixing it for you.
Is the ass border the one in the south?
We've got some smart border agents.
No. You've got borderline smart agents. There's a difference.
Better to say "I've done this in the past, and have a working version" or "I've got a demo at home".
Stupid - if it is already done by yourself and exists (even prior to you joining the company), then the company will simply claim it. Fighting for ownership of a product, even with overwhelming evidence on your side, will cost more money that you make in a year. Add to this the fact that you'll be unemployed while fighting for ownership.
Don't be stupid, be smart - if you have already created a product (or parts of one) then don't offer it to your company (don't even let them know it exists), simply leave and start your own company.
Fors is still claiming it plans to hold to that 5 year timeframe (2021), and Nissan is aiming for 2020. I think you're underestimating the amount of work the big manufacturers and parts suppliers have been putting into this.
In some cases the amount of effort put into something is irrelevant.
For example, the amount of work put into solving the halting problem doesn't mean that a solution will be found (or that it exists). In this case quite a lot of folk are working on the assumption that SDC's can be done without general AI. Personally I doubt it, but even my most optimistic predictions for AI smart enough to drive a car in the conditions that humans do place it several decades out (general purpose AI).
Brute-forcing a problem to find a solution is easy. SDC's need more than that.
In my opinion, the reason why Apple and Google have pulled out is not that the technology does not work, but that it is not yet demonstrably sufficiently reliable, and that cheap sensors that make the technology both feasible and economic are not out yet.
The sensors are the easy part. The hardware is a solved problem. It's the software that is the problem. With hardware you can look at something that is 99% complete and make a pretty good guess about what to put into the missing 1% to solve the problem. Software that is 99% there may never be 100%, not matter what you do.
Some problems are not solvable even with all the computing power in the world. Those tend to be the software problems (AKA the math problems). SDC's have already solved the hardware problem for the last two decades. They haven't made much progress solving the software problems. At this point there is no indication that the software problem is solvable within our lifetime.
Over a year ago, when schmucks were saying that SDC's were just around the corner (five years time) I pointed out that SDC's were mostly at the same level in the mid-nineties as they are now, with improvements barely incremental.
Of course, I got told that things have changed, that large strides have been made and that revolutionary improvements have appeared for SDC. Bull, of course.
Since the mid-nineties the hardware used for SDC has increased in computational power by perhaps four orders of magnitude (1000000%) while the SDC capability (how often a human has to intervene to correct is one measure) has increased by perhaps 2%. This is not a sign of improvement.
It doesn't matter how low the accident rate for SDC's go if they do not go to absolute zero.
If you, the customer, want to allow the manufacturer to dodge the liability in their product, then fine - go ahead and do it. However, if that product then harms me on a public road, the manufacturer doesn't get to claim "Well, our customer agreed to the EULA".
The "low accident rate makes it moot" only makes it moot for those who accept it - i.e. the SDC customer. Unfortunately for the manufacturer, any defect in their product that harms a third party means that the manufacturer is still liable.
That's the current law. I do not foresee any changes to it to accomodate self-driving cars. In fact, I would vigourously oppose any law that prevents me from taking a manufacturer to task for an error made in the decision-making in its product.
Did you even read my post? It was not about the article. The headline is beyond stupid. If you wish to reply to something other than what I wrote then feel free, but don't be critical of me for it.
No, I wrote a judgement about the headline based upon the headline and very clearly wrote that I was doing so.
This does not look like a critique of the headline:
Beyond stupid - the people in charge of children and livestock are found culpable so why let people in charge of something with less brains than either off? When we've got an A.I. like the fictional ones of HAL or Colossus it's time to revise the rules, but finding a lookup table culpable? Beyond stupid.
That's word for word what you wrote - here's the link.
In what way is that making the self driving car liable?
It's making the manufacturer liable. Seriously, did you even RTFA?
Where the manufacturer is found to be liable, the insurer will be able to pursue a subrogated claim against the manufacturer under existing common law and product liability arrangements and recover their costs from the manufacturer.
Now do you understand?
The headline is beyond stupid.
Then to avoid misconceptions you should have maybe read the article. Even the summary makes the point that if the passenger is not liable then the manufacturer is.
I note that initially you didn't specifically call out the headline as being stupid, you just generally called the story stupid.
The machine itself should IMHO not liable whether the manufacturer, programmer, passenger or mapmaker is or not. If someone fucks up the lookup table that people call an A.I. then that person or their employer should be liable instead of some stupid fiction about a car being able to make choices and found to be responsible.
That fiction is only in the headline. The article *and* the summary clarifies things. You make judgements about all articles based on clickbait headlines?
Beyond stupid - the people in charge of children and livestock are found culpable so why let people in charge of something with less brains than either off?
The people in charge of the SDC is the manufacturer, not the passenger. The manufacturer determines how the car drives. The passenger only determines the destination. Do you also think that you are liable if you're in a taxi that gets involved in an accident?
What do you mean "initially".
What I mean is that eventually, when the bugs have been worked out and only automated cars are allowed to use most of the lanes on the interstate and the accident rate stabilizes (hopefully near zero) then the burden will be shifted from the automakers to the customers, who will pay for it along with the rest of their mandatory liability insurance. The insurers aren't going to deal with insuring vehicles individually until the risk is reasonably estimable.
Why should the customer *ever* be liable for a malfunctioning car? If it is supposed to self-drive and it doesn't, then that's not my fault, it's the fault of the manufacturer.
Car makers are selling Autopilot knowing full well that the people behind the wheel will be texting/surfing on their phones or in car entertainment systems.
Car makers are selling cars without Autopilot knowing full well that the people behind the wheel will be texting/surfing on their phones or in car entertainment systems.
And the manufacturer then doesn't have any liability. It sounds like you are in agreement with parent.
I agree, documentation of protocols needs to be improved; however, it's hard to document everything you did for a paper when the journal doesn't give you very many words at all to actually explain what you did, and many don't support video sections for online papers.
Video is almost always less information-dense than text. Why would you want to spend ten minutes watching something that can be read in 60 seconds?
Dereferencing the virtual address 0x72 is guaranteed to crash an application when the OS is designed never to map the first (usually 4K) addresses. Accessing that memory causes a page fault, the OS searches the page table for the corresponding page mapping, fails to find a valid mapping, so you get a segmentation fault.
This has nothing to do with C though. C says the behavior is "undefined" if you set a pointer to a location that is not used to store a C object.
We've already agreed that it's undefined behaviour. What we're arguing are the circumstances that this particular invocation of UB would result in a crash. Just because something is UB doesn't mean that it consistently crashes at the point of UB.
Oh, it can. It just won't do it reliably. Setting a string pointer to 0x72 will certainly do.
It can. It might not though. It depends, actually, on whether it is ever deferenced or not. The original *s = 'H' can crash without ever needing any more derefencing. Your correction can (not 'will', but 'can') crash only if it is dereferenced.
Setting it is not enough, you have to dereference it as well. Although now that I think about it, depending on the platform, simply dereferencing it may still not be enough.
For example, I just tried it now, verbatim, in the OS kernel I hobby-developed and it worked just fine reading from it. Of course, it returned some random address stored in the interrupt vector table, but it did not crash!
I can also write to it too - I've not yet filled in the IVT so no interrupt number is using those numbers ... yet! The OS is probably going to use int-0x80 and storing 12 bytes at 0x72 will not reliably overwrite address 0x80. At the current alignment it certainly will not. A single character more will take the total to 13 + alignment padding = 16 bytes total, which is 0x72. A bad jump here will probably reboot, which we can safely judge to be a crash.
I think you meant s = 'H'; there....
No, he is correct that *s = 'H' can segfault. You aren't allowed to modify string literals, only char arrays.
I guess the Russians flooding the internet with fake news in order to delegitimize every single news organization is not hacking? I'm not convinced there was voting machine hacking, but the Russians definitely engaged in social hacking in a concerted effort to boost Trump.
Lemme guess, you hate Woodward and Bernstein too right? They influenced presidential politics the same way you think those 'commie bastards' influenced the election.
"Those election-hacking Russians" is the new "those commie bastards".
You'll have to excuse me for not falling for this now, the way I didn't fall for it 30 years ago.