Sorry I am not going to lose more time in this thread but do you understand the customer then verifies the bug really got fixed? When it crashed 1000 times before the fix and not crashed 1000 times after the fix do you still insist the package maintainer fixed an unrelated bug? After all even if it was an unrelated bug it fixed the problem of the customer which is all what matters. With all the messy code in use it is usually difficult to say what is a related and unrelated bug in the code as some code usually depends on wrong results from some other code. We do not live in a world of mathematically 100% proven programs, we are too far from that.
That's a normal state of Bug that it cannot by verified by author of the fix. I have made tons of such bugfixes. In Red Hat Bugzilla such Bugs have keyword "OtherQA".
I can verify that. I have already 148 lines of/proc/mounts here again (so it happens even with my current PC setup). Sure I cannot verify it for 100% ("evidence of absence").
I do not know where to put the printks off the top of my head as I am not a kernel developer. I provide similar debugging services for GDB where I know the codebase thoroughly. I could read+learn the kernel sources to find out where to put the printks but that does not scale, life is too short to know very every line of system sources, that is what developers specialization is there for.
The problem happens due to my scripts running nightly regression testing of various toolchain components in various (chrooted) operating system variants/versions. Currently I "do not do that" as you suggest because of that bug. Therefore users hit+bugreport those regressions. Formerly I was fixing the regressions before any user could hit them, that was a so-called proactive solution. Yes, I could code the scripts some other way (such as using KVM instead of chroot) but that would be a workaround, the scripts are not buggy, the kernel is. I can provide the scripts but there are many of them and setting up the whole system for them is not easy, it was done ad hoc: 1234
I am the bug filer. I had the Bug reproducible locally but I could not provide reproducer. If kernel developers provided me some patch adding debug printks I would send them back the debug output so they can track it down. But I do not remember anyone would ever deal with any kernel bug I filed.
I am the Fedora user. And I haven't seen the problem fixed, just since that time I replaced/reconfigured my RAID and I no longer have the problem reproducible, hopefully.
I still have no idea what a phone could be good for except for some emergency call once a year. Free software gets written when someone needs the functionality. Nobody really needs some beeping gadget. And you could talk the same in 1995 - look what MS-Windows 95 can do and Linux still does not even have Plug&Play! That Free software is a complete useless crap!
VMs are a poor man's a workaround of missing microkernel features. Do you mount all your filesystems just via a VM? And if you do then all the user programs have to run inside that VM. And so restarting the VM is as painful as restarting the whole machine. What's the point of such VM then?
Thanks to the microkernel architecture you will no longer have to reboot system just to get rid of that stale lock on an accidentally removed USB disk or unmountable --bind mount in/proc/mounts due to non-existing user/usecount or due to some crashed driver locking up your PCI device etc. I could transparently restart crashed ntfs.sys emulated under Linux in 2003 while Linux kernel still can't do that with its native filesystems.
Motherboard manufacturer can do whatever they want but unless I reflash my BIOS it has no effect. And I do not regularly reflash my BIOS, do you? Besides that I still find the automatic nightly package update easier.
Musk in some video said that reusing the stage 2 would be definitely possible but that he does not plan to do that. That he has more interesting challenges ahead such as the Mars.
That surprised me a bit, he employs engineers to implement the reusability.
If it was not clear I do not use software not packaged by the distro. It has then many consequences such as difficult/non-standard/missing updates, incompatible build-ids for automatic distro Bugs/crashes reporting and after all one has trust another package signing entity besides the distro one.
I do not use Chrome because it is insecure - it is not Free, I do not have sources for it. I could use Chromium but that is not shipped in Fedora (it is in Fedora COPR repository but there may be some "but" when it is not shipped by default and it is just not easy enough).
$subj is another part breaking modern Linux OSes which we should get rid of.
Each month a new breakage, this month it is USB speakers invisible to software playing via pulseaudio while still addressable as an ALSA device.
Slashdot Mirror
Sorry I am not going to lose more time in this thread but do you understand the customer then verifies the bug really got fixed? When it crashed 1000 times before the fix and not crashed 1000 times after the fix do you still insist the package maintainer fixed an unrelated bug? After all even if it was an unrelated bug it fixed the problem of the customer which is all what matters. With all the messy code in use it is usually difficult to say what is a related and unrelated bug in the code as some code usually depends on wrong results from some other code. We do not live in a world of mathematically 100% proven programs, we are too far from that.
That's a normal state of Bug that it cannot by verified by author of the fix. I have made tons of such bugfixes. In Red Hat Bugzilla such Bugs have keyword "OtherQA".
I can verify that. I have already 148 lines of /proc/mounts here again (so it happens even with my current PC setup). Sure I cannot verify it for 100% ("evidence of absence").
I do not know where to put the printks off the top of my head as I am not a kernel developer. I provide similar debugging services for GDB where I know the codebase thoroughly. I could read+learn the kernel sources to find out where to put the printks but that does not scale, life is too short to know very every line of system sources, that is what developers specialization is there for.
The problem happens due to my scripts running nightly regression testing of various toolchain components in various (chrooted) operating system variants/versions. Currently I "do not do that" as you suggest because of that bug. Therefore users hit+bugreport those regressions. Formerly I was fixing the regressions before any user could hit them, that was a so-called proactive solution. Yes, I could code the scripts some other way (such as using KVM instead of chroot) but that would be a workaround, the scripts are not buggy, the kernel is. I can provide the scripts but there are many of them and setting up the whole system for them is not easy, it was done ad hoc: 1 2 3 4
I do not see this Bug would be fixed and I never said that. Why do you think it is fixed?
I am the bug filer. I had the Bug reproducible locally but I could not provide reproducer. If kernel developers provided me some patch adding debug printks I would send them back the debug output so they can track it down. But I do not remember anyone would ever deal with any kernel bug I filed.
I am the Fedora user. And I haven't seen the problem fixed, just since that time I replaced/reconfigured my RAID and I no longer have the problem reproducible, hopefully.
I still have no idea what a phone could be good for except for some emergency call once a year. Free software gets written when someone needs the functionality. Nobody really needs some beeping gadget. And you could talk the same in 1995 - look what MS-Windows 95 can do and Linux still does not even have Plug&Play! That Free software is a complete useless crap!
HURD can become a non-crashing OS one day, Linux with its current architecture cannot. Everything has its pros and cons, pick your poison.
The sooner you will write that the sooner you will get it. That's all what Free software guarantees you and I find it superior to anything else.
You have to reboot that box about each two weeks: Fedora kernel Bug 1183791 (it is probably not specific to Fedora)
You can run Linux-libre for the OS part, that is much easier target than GNU Hurd.
VMs are a poor man's a workaround of missing microkernel features. Do you mount all your filesystems just via a VM? And if you do then all the user programs have to run inside that VM. And so restarting the VM is as painful as restarting the whole machine. What's the point of such VM then?
Thanks to the microkernel architecture you will no longer have to reboot system just to get rid of that stale lock on an accidentally removed USB disk or unmountable --bind mount in /proc/mounts due to non-existing user/usecount or due to some crashed driver locking up your PCI device etc. I could transparently restart crashed ntfs.sys emulated under Linux in 2003 while Linux kernel still can't do that with its native filesystems.
Motherboard manufacturer can do whatever they want but unless I reflash my BIOS it has no effect. And I do not regularly reflash my BIOS, do you? Besides that I still find the automatic nightly package update easier.
Isn't it easier to distibute new firmware with microcode_ctl/intel-microcode packages? MS-Windows also seems to have some such package updates.
Because it should be better than Perl 5 and there isn't anything better than Perl 5.
Musk in some video said that reusing the stage 2 would be definitely possible but that he does not plan to do that. That he has more interesting challenges ahead such as the Mars.
That surprised me a bit, he employs engineers to implement the reusability.
s/Ubuntu/Linux/ in your post and then we can agree. Those two terms are not equal.
Edge is finally opensource and crossplatform?
If it was not clear I do not use software not packaged by the distro. It has then many consequences such as difficult/non-standard/missing updates, incompatible build-ids for automatic distro Bugs/crashes reporting and after all one has trust another package signing entity besides the distro one.
I do not use Chrome because it is insecure - it is not Free, I do not have sources for it. I could use Chromium but that is not shipped in Fedora (it is in Fedora COPR repository but there may be some "but" when it is not shipped by default and it is just not easy enough).
'nuff said
$subj is another part breaking modern Linux OSes which we should get rid of. Each month a new breakage, this month it is USB speakers invisible to software playing via pulseaudio while still addressable as an ALSA device.
T9 is easy to write but difficult to read. :-)