Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86221 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2022-09-09 12:49 -0500 |
| Last post | 2022-09-22 19:21 +0000 |
| Articles | 20 on this page of 92 — 19 participants |
Back to article view | Back to comp.lang.c++
"Richard Stallman Announces C Reference" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-09 12:49 -0500
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-09 19:03 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-10 18:16 +0200
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-10 17:04 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 08:29 +0000
Re: "Richard Stallman Announces C Reference" Manfred <noname@add.invalid> - 2022-09-24 16:24 +0200
C++ is for real, C is just a toy (Was: "Richard Stallman Announces C Reference") gazelle@shell.xmission.com (Kenny McCormack) - 2022-09-24 15:54 +0000
Re: C++ is for real, C is just a toy (Was: "Richard Stallman Announces C Reference") Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 18:07 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 08:29 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 11:16 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 09:44 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 13:42 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 15:44 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 17:55 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-11 16:17 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:22 +0200
Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-11 12:41 -0700
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 06:10 +0200
Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-12 00:27 -0700
Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 09:18 +0200
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 09:42 +0200
Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 12:05 +0200
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 12:12 +0200
Re: "Richard Stallman Announces C Reference" Manfred <noname@add.invalid> - 2022-09-24 16:31 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-12 15:58 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-12 18:48 +0200
Re: "Richard Stallman Announces C Reference" Bo Persson <bo@bo-persson.se> - 2022-09-12 20:32 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-13 13:27 +0000
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-13 22:33 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 06:04 +0000
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-14 10:38 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 12:21 +0000
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-15 12:15 -0700
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-16 06:02 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-16 10:37 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-16 11:05 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-16 13:18 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-16 16:00 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-16 15:16 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-18 12:13 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 05:45 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-19 08:33 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 10:41 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-19 13:48 +0200
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-19 15:22 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-16 13:10 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 05:51 +0000
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-19 12:27 -0700
Re: "Richard Stallman Announces C Reference" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-16 11:19 -0700
Re: "Richard Stallman Announces C Reference" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 06:56 -0700
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-16 14:29 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-16 17:04 +0200
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-16 08:24 -0700
Re: "Richard Stallman Announces C Reference" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 09:00 -0700
Re: "Richard Stallman Announces C Reference" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-09-15 00:54 +0100
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-15 05:31 +0000
Re: "Richard Stallman Announces C Reference" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-09-15 10:19 +0100
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 12:41 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-14 09:16 +0200
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-14 10:29 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-14 15:55 +0200
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-16 20:16 +0000
Re: "Richard Stallman Announces C Reference" Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-16 16:55 -0500
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-16 22:21 +0000
Re: "Richard Stallman Announces C Reference" Andreas Kempe <kempe@lysator.liu.se> - 2022-09-17 14:52 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 06:06 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-18 12:34 +0200
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-18 12:22 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-19 06:11 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-19 10:14 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 12:12 +0000
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-14 15:58 +0200
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-13 06:47 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-13 13:29 +0000
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-14 05:56 +0000
Re: "Richard Stallman Announces C Reference" Muttley@dastardlyhq.com - 2022-09-14 09:37 +0000
boost::intrusive. Was: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-11 09:51 -0700
Re: boost::intrusive. Was: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:55 +0200
Re: "Richard Stallman Announces C Reference" scott@slp53.sl.home (Scott Lurndal) - 2022-09-11 16:26 +0000
Re: "Richard Stallman Announces C Reference" Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-11 18:35 +0200
Re: "Richard Stallman Announces C Reference" Opus <ifonly@youknew.org> - 2022-09-12 19:22 +0200
Re: "Richard Stallman Announces C Reference" legalize+jeeves@mail.xmission.com (Richard) - 2022-09-22 19:24 +0000
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-10 12:56 -0700
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-10 15:53 -0700
Re: "Richard Stallman Announces C Reference" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-09-11 07:07 +0200
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-11 16:17 -0700
Re: "Richard Stallman Announces C Reference" David Brown <david.brown@hesbynett.no> - 2022-09-11 13:50 +0200
Re: "Richard Stallman Announces C Reference" Michael S <already5chosen@yahoo.com> - 2022-09-11 05:53 -0700
Re: "Richard Stallman Announces C Reference" Juha Nieminen <nospam@thanks.invalid> - 2022-09-12 05:47 +0000
Re: "Richard Stallman Announces C Reference" Manu Raju <MR@invalid.invalid> - 2022-09-11 00:01 +0100
Re: "Richard Stallman Announces C Reference" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-10 16:26 -0700
Re: "Richard Stallman Announces C Reference" legalize+jeeves@mail.xmission.com (Richard) - 2022-09-22 19:21 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-12 09:42 +0200 |
| Message-ID | <tfmnsn$277td$1@dont-email.me> |
| In reply to | #86277 |
Am 12.09.2022 um 09:18 schrieb Bo Persson: > On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >> On Sun, 11 Sep 2022 13:42:20 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>> >>>> The necessity is for a language that can have embedded assembler, is >>>> very >>>> efficient to compile and once compiled and is explicit. Because of this >>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>> out which doesn't leave much left thats an advantage over C. >>> >>> That all isn't a problem in the kernel if you know what you do. >>> Kernel-Programmers are very skilled and the should be able to >>> handle that, but it's not up to their mindset. >> >> Its nothing to do with their mindset, its to do with knowing EXACTLY >> what the >> code is going to do and/or where the program counter is going to go. > > I have never understood how you can know EXACTLY what the code does in > > int y = f(x); > > but have no clue about what happens in > > my_class f(x); That's a function that returns a my_class object. This object is mostly moved from inside f( x ). if f( x ) is inlined this move is optimized away.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-09-12 12:05 +0200 |
| Message-ID | <jo8ejdFpi8cU1@mid.individual.net> |
| In reply to | #86279 |
On 2022-09-12 at 09:42, Bonita Montero wrote: > Am 12.09.2022 um 09:18 schrieb Bo Persson: >> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >>> On Sun, 11 Sep 2022 13:42:20 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>>> >>>>> The necessity is for a language that can have embedded assembler, >>>>> is very >>>>> efficient to compile and once compiled and is explicit. Because of >>>>> this >>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>>> out which doesn't leave much left thats an advantage over C. >>>> >>>> That all isn't a problem in the kernel if you know what you do. >>>> Kernel-Programmers are very skilled and the should be able to >>>> handle that, but it's not up to their mindset. >>> >>> Its nothing to do with their mindset, its to do with knowing EXACTLY >>> what the >>> code is going to do and/or where the program counter is going to go. >> >> I have never understood how you can know EXACTLY what the code does in >> >> int y = f(x); >> >> but have no clue about what happens in >> >> my_class f(x); > > That's a function that returns a my_class object. It's a function only if x is a type. But x is a value, like in the int case, so it is a constructor call. > This object is mostly moved from inside f( x ). > if f( x ) is inlined this move is optimized away. And still, the C guys cannot see what happens here. So "improve" this as struct my_class f; init(&f, x); And now it is suddenly obvious EXACTLY what happens? :-)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-12 12:12 +0200 |
| Message-ID | <tfn0m9$281g0$1@dont-email.me> |
| In reply to | #86282 |
Am 12.09.2022 um 12:05 schrieb Bo Persson: > On 2022-09-12 at 09:42, Bonita Montero wrote: >> Am 12.09.2022 um 09:18 schrieb Bo Persson: >>> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >>>> On Sun, 11 Sep 2022 13:42:20 +0200 >>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>>>> >>>>>> The necessity is for a language that can have embedded assembler, >>>>>> is very >>>>>> efficient to compile and once compiled and is explicit. Because of >>>>>> this >>>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>>>> out which doesn't leave much left thats an advantage over C. >>>>> >>>>> That all isn't a problem in the kernel if you know what you do. >>>>> Kernel-Programmers are very skilled and the should be able to >>>>> handle that, but it's not up to their mindset. >>>> >>>> Its nothing to do with their mindset, its to do with knowing EXACTLY >>>> what the >>>> code is going to do and/or where the program counter is going to go. >>> >>> I have never understood how you can know EXACTLY what the code does in >>> >>> int y = f(x); >>> >>> but have no clue about what happens in >>> >>> my_class f(x); >> >> That's a function that returns a my_class object. > > It's a function only if x is a type. But x is a value, like in the int > case, so it is a constructor call. > >> This object is mostly moved from inside f( x ). >> if f( x ) is inlined this move is optimized away. > > And still, the C guys cannot see what happens here. So "improve" this as The C++-"guys" can ! > > struct my_class f; > init(&f, x); > > And now it is suddenly obvious EXACTLY what happens? :-) > > >
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-09-24 16:31 +0200 |
| Message-ID | <tgn4bf$5k1$1@gioia.aioe.org> |
| In reply to | #86282 |
On 9/12/2022 12:05 PM, Bo Persson wrote: > On 2022-09-12 at 09:42, Bonita Montero wrote: >> Am 12.09.2022 um 09:18 schrieb Bo Persson: >>> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >>>> On Sun, 11 Sep 2022 13:42:20 +0200 >>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>>>> >>>>>> The necessity is for a language that can have embedded assembler, >>>>>> is very >>>>>> efficient to compile and once compiled and is explicit. Because of >>>>>> this >>>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>>>> out which doesn't leave much left thats an advantage over C. >>>>> >>>>> That all isn't a problem in the kernel if you know what you do. >>>>> Kernel-Programmers are very skilled and the should be able to >>>>> handle that, but it's not up to their mindset. >>>> >>>> Its nothing to do with their mindset, its to do with knowing EXACTLY >>>> what the >>>> code is going to do and/or where the program counter is going to go. >>> >>> I have never understood how you can know EXACTLY what the code does in >>> >>> int y = f(x); >>> >>> but have no clue about what happens in >>> >>> my_class f(x); >> >> That's a function that returns a my_class object. > > It's a function only if x is a type. But x is a value, like in the int > case, so it is a constructor call. > Ironically, I think this kind of proves the case. >> This object is mostly moved from inside f( x ). >> if f( x ) is inlined this move is optimized away. > > And still, the C guys cannot see what happens here. So "improve" this as > > struct my_class f; > init(&f, x); > > And now it is suddenly obvious EXACTLY what happens? :-) > :)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-12 15:58 +0000 |
| Message-ID | <tfnkvj$og$1@gioia.aioe.org> |
| In reply to | #86277 |
On Mon, 12 Sep 2022 09:18:44 +0200 Bo Persson <bo@bo-persson.se> wrote: >On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >> On Sun, 11 Sep 2022 13:42:20 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>> >>>> The necessity is for a language that can have embedded assembler, is very >>>> efficient to compile and once compiled and is explicit. Because of this >>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>> out which doesn't leave much left thats an advantage over C. >>> >>> That all isn't a problem in the kernel if you know what you do. >>> Kernel-Programmers are very skilled and the should be able to >>> handle that, but it's not up to their mindset. >> >> Its nothing to do with their mindset, its to do with knowing EXACTLY what the > >> code is going to do and/or where the program counter is going to go. > >I have never understood how you can know EXACTLY what the code does in > >int y = f(x); > >but have no clue about what happens in > >my_class f(x); And if that instance has virtual functions where will the VFT go and what allocates it? Ditto any non primitive types which may cause an implcit cascade of allocations. People like yourself and Bonita just don't seem to get the fact that there's no safety net inside ring 0 code. You can't just handwave away stuff that in application code would be taken care of by the runtime.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-12 18:48 +0200 |
| Message-ID | <tfnnrp$2a1cl$1@dont-email.me> |
| In reply to | #86288 |
Am 12.09.2022 um 17:58 schrieb Muttley@dastardlyhq.com: > On Mon, 12 Sep 2022 09:18:44 +0200 > Bo Persson <bo@bo-persson.se> wrote: >> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >>> On Sun, 11 Sep 2022 13:42:20 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>>> >>>>> The necessity is for a language that can have embedded assembler, is very >>>>> efficient to compile and once compiled and is explicit. Because of this >>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>>> out which doesn't leave much left thats an advantage over C. >>>> >>>> That all isn't a problem in the kernel if you know what you do. >>>> Kernel-Programmers are very skilled and the should be able to >>>> handle that, but it's not up to their mindset. >>> >>> Its nothing to do with their mindset, its to do with knowing EXACTLY what the >> >>> code is going to do and/or where the program counter is going to go. >> >> I have never understood how you can know EXACTLY what the code does in >> >> int y = f(x); >> >> but have no clue about what happens in >> >> my_class f(x); > > And if that instance has virtual functions where will the VFT go and what > allocates it? Ditto any non primitive types which may cause an implcit cascade > of allocations. > > People like yourself and Bonita just don't seem to get the fact that there's no > safety net inside ring 0 code. You can't just handwave away stuff that in > application code would be taken care of by the runtime. > You're mentally like ring 0 - the whole day.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-09-12 20:32 +0200 |
| Message-ID | <jo9c9lFu516U1@mid.individual.net> |
| In reply to | #86288 |
On 2022-09-12 at 17:58, Muttley@dastardlyhq.com wrote: > On Mon, 12 Sep 2022 09:18:44 +0200 > Bo Persson <bo@bo-persson.se> wrote: >> On 2022-09-11 at 17:44, Muttley@dastardlyhq.com wrote: >>> On Sun, 11 Sep 2022 13:42:20 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Am 11.09.2022 um 11:44 schrieb Muttley@dastardlyhq.com: >>>> >>>>> The necessity is for a language that can have embedded assembler, is very >>>>> efficient to compile and once compiled and is explicit. Because of this >>>>> C++'s hidden conversions, exceptions and most of the STL can be ruled >>>>> out which doesn't leave much left thats an advantage over C. >>>> >>>> That all isn't a problem in the kernel if you know what you do. >>>> Kernel-Programmers are very skilled and the should be able to >>>> handle that, but it's not up to their mindset. >>> >>> Its nothing to do with their mindset, its to do with knowing EXACTLY what the >> >>> code is going to do and/or where the program counter is going to go. >> >> I have never understood how you can know EXACTLY what the code does in >> >> int y = f(x); >> >> but have no clue about what happens in >> >> my_class f(x); > > And if that instance has virtual functions where will the VFT go and what > allocates it? Ditto any non primitive types which may cause an implcit cascade > of allocations. Just don't see how we know that int y = f(x); doesn't call other functions that allocate structs on the heap? Structs that contain function pointers that are then called, cause an implicit cascade of allocations. > > People like yourself and Bonita just don't seem to get the fact that there's no > safety net inside ring 0 code. You can't just handwave away stuff that in > application code would be taken care of by the runtime. > You can look at the class declaration to see what the constructor does - and that there are no virtual functions present. Just like you have to verify what the C function does.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-13 13:27 +0000 |
| Message-ID | <tfq0gl$16s3$1@gioia.aioe.org> |
| In reply to | #86291 |
On Mon, 12 Sep 2022 20:32:21 +0200 Bo Persson <bo@bo-persson.se> wrote: >On 2022-09-12 at 17:58, Muttley@dastardlyhq.com wrote: >>> my_class f(x); >> >> And if that instance has virtual functions where will the VFT go and what >> allocates it? Ditto any non primitive types which may cause an implcit >cascade >> of allocations. > >Just don't see how we know that int y = f(x); doesn't call other >functions that allocate structs on the heap? Structs that contain It may well do, but you can at least look at them to see how and kernel authors are extremely careful about how they allocate dynamic memory. Meanwhile who knows if std::string s = "hello" will allocate on the heap or if it'll use its small reerved amount of stack.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kempe <kempe@lysator.liu.se> |
|---|---|
| Date | 2022-09-13 22:33 +0000 |
| Message-ID | <tfr0f0$2ppo$1@nyheter.lysator.liu.se> |
| In reply to | #86298 |
Den 2022-09-13 skrev Muttley@dastardlyhq.com <Muttley@dastardlyhq.com>: > On Mon, 12 Sep 2022 20:32:21 +0200 > Bo Persson <bo@bo-persson.se> wrote: >>On 2022-09-12 at 17:58, Muttley@dastardlyhq.com wrote: >>>> my_class f(x); >>> >>> And if that instance has virtual functions where will the VFT go and what >>> allocates it? Ditto any non primitive types which may cause an implcit >>cascade >>> of allocations. >> >>Just don't see how we know that int y = f(x); doesn't call other >>functions that allocate structs on the heap? Structs that contain > > It may well do, but you can at least look at them to see how and kernel authors > are extremely careful about how they allocate dynamic memory. Meanwhile > who knows if std::string s = "hello" will allocate on the heap or if it'll > use its small reerved amount of stack. > > In my view, this is not a language problem as much as a standard library implementation problem. As have been brought up earlier, you don't use the normal user space libc in the kernel for C code, but have parts of the standard library implemented in a way to make it fit the kernel. To seriously bring C++ into the kernel world, one would have to do the same. That is, pick functions from the standard library that make sense in the kernel and implement them to work there. One such thing could of course be an std::string without hidden heap allocations. I, and doubtlessly many others, have long toyed with the idea that kernel programming, Linux or *BSD is what I'm familiar with, could be made simpler with a language that supports object oriented programming instead of using C structs with function pointers. The possibility of doing RAII would also be nice. Whether that language should be C++ is another question and I don't have a good answer.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-14 06:04 +0000 |
| Message-ID | <tfrqtu$1ges$1@gioia.aioe.org> |
| In reply to | #86302 |
Andreas Kempe <kempe@lysator.liu.se> wrote: > I, and doubtlessly many others, have long toyed with the idea that > kernel programming, Linux or *BSD is what I'm familiar with, could be > made simpler with a language that supports object oriented programming > instead of using C structs with function pointers. The possibility of > doing RAII would also be nice. Whether that language should be C++ is > another question and I don't have a good answer. One of the stated reasons why the Linux kernel sticks with C is that it's the kind of "lingua franca" of programming languages, when it comes to low-level programming in general and Linux kernel development in particular. Existing developers don't need to learn a new programming language in order to eg. do code reviews of new submissions, or interact with other parts of the code in their code. If a new language were to be introduced into kernel code, like C++ (or, heaven forbid, Rust), that would mean that a huge amount of devs would either need to learn the new language or just don't participate (in code reviews, further development, etc), which would ostensibly mean a significant drop in the number of expert developers. The kernel is complex enough as it is; it would not benefit from half the developers dropping off (and perhaps creating their own fork and going there). I'm not completely unsympathetic to that reasoning. But yeah, some of the most complicated kernel drivers could perhaps benefit from RAII and templates, if they were available.
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kempe <kempe@lysator.liu.se> |
|---|---|
| Date | 2022-09-14 10:38 +0000 |
| Message-ID | <tfsau8$iac$2@nyheter.lysator.liu.se> |
| In reply to | #86305 |
Den 2022-09-14 skrev Juha Nieminen <nospam@thanks.invalid>: > Andreas Kempe <kempe@lysator.liu.se> wrote: >> I, and doubtlessly many others, have long toyed with the idea that >> kernel programming, Linux or *BSD is what I'm familiar with, could be >> made simpler with a language that supports object oriented programming >> instead of using C structs with function pointers. The possibility of >> doing RAII would also be nice. Whether that language should be C++ is >> another question and I don't have a good answer. > > One of the stated reasons why the Linux kernel sticks with C is that it's > the kind of "lingua franca" of programming languages, when it comes > to low-level programming in general and Linux kernel development in > particular. Existing developers don't need to learn a new programming > language in order to eg. do code reviews of new submissions, or interact > with other parts of the code in their code. > > If a new language were to be introduced into kernel code, like C++ > (or, heaven forbid, Rust), that would mean that a huge amount of devs > would either need to learn the new language or just don't participate > (in code reviews, further development, etc), which would ostensibly > mean a significant drop in the number of expert developers. The kernel > is complex enough as it is; it would not benefit from half the > developers dropping off (and perhaps creating their own fork and > going there). > > I'm not completely unsympathetic to that reasoning. > This might be part of the reasoning, but I think the main reason is that Linus is biased against C++ on the grounds of simply not liking the language. Here's a quote I managed to find again from when they were discussing Rust support in the kernel: >Asked about a suggestion by a commenter on the Linux Weekly News >website, who said, during a discussion on the Google post, "The >solution here is simple: just use C++ instead of Rust", Torvalds >could not restrain himself from chortling. "LOL," was his response. >"C++ solves _none_ of the C issues, and only makes things worse. It >really is a crap language. > >"For people who don't like C, go to a language that actually offers >you something worthwhile. Like languages with memory safety and >[which] can avoid some of the dangers of C, or languages that have >internal GC [garbage collection] support and make memory management >easier. C++ solves all the wrong problems, and anybody who says >'rewrite the kernel in C++' is too ignorant to even know that." Source: https://developers.slashdot.org/story/21/04/17/009241/linus-torvalds-says-rust-closer-for-linux-kernel-development-calls-c-a-crap-language > But yeah, some of the most complicated kernel drivers could perhaps > benefit from RAII and templates, if they were available. From my personal experince, it doesn't even have to be complex drivers. The first pattern I would be happy to throw out is all the goto cleanup;, goto unlock;, goto exit; etc you have to sprinkle throughout the code as soon as you need to allocate or lock something.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-14 12:21 +0000 |
| Message-ID | <tfsgvb$1vug$1@gioia.aioe.org> |
| In reply to | #86315 |
Andreas Kempe <kempe@lysator.liu.se> wrote: > This might be part of the reasoning, but I think the main reason is > that Linus is biased against C++ on the grounds of simply not liking > the language. > > Here's a quote I managed to find again from when they were discussing > Rust support in the kernel: I still find it astonishing how much unprofessionalism there is in the Linux development scene, even at the highest levels. Just read the cringe language used in the *official* Linux kernel coding style guideline page: https://www.kernel.org/doc/html/v4.10/process/coding-style.html (I'm not talking about the coding style itself, but the explanatory text.) This kind of unprofessional language and attitude would have been understandable in the 1990's, when Linux was just a really small hobby project used by only a handful of people. It's significantly less understandable today, when Linux is one of the most if not the most used operating system in the world, used in and by extremely large institutions and international corporations, and people who contribute to its kernel code include giant tech megacorporations. Just imagine doing business with a giant corporation, and using language like that. It's astonishingly unprofessional and cringe.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2022-09-15 12:15 -0700 |
| Message-ID | <088ac17f-3651-4dbf-b4c0-96fb7bec2efbn@googlegroups.com> |
| In reply to | #86319 |
On Wednesday, September 14, 2022 at 3:21:17 PM UTC+3, Juha Nieminen wrote: > Andreas Kempe <ke...@lysator.liu.se> wrote: > > This might be part of the reasoning, but I think the main reason is > > that Linus is biased against C++ on the grounds of simply not liking > > the language. > > > > Here's a quote I managed to find again from when they were discussing > > Rust support in the kernel: > I still find it astonishing how much unprofessionalism there is in the > Linux development scene, even at the highest levels. > > Just read the cringe language used in the *official* Linux kernel coding > style guideline page: > https://www.kernel.org/doc/html/v4.10/process/coding-style.html > > (I'm not talking about the coding style itself, but the explanatory text.) > I like the language of this text. Style itself - less so; agree or accept with 80%, but not with another 20%. It seems, what you consider "professional language" I'd consider boring and bureaucratic. Or, may be, not. In order to know for sure you have to give me an example of what you consider well-written style guide. Of course, there is another problem: anarchistic part of me dislikes the whole idea of style guides so when style guide is written in mundane style it just adds insult to the injury. On the other hand "mundane" style is not the worst in my book, what drives me more crazy is "wake" style. Fortunately, "wake" is more likely to be encountered in "codes of conduct" and less likely in "style guides". And since in my book "codes of conduct" are sort of humorous prose anyway, even when athors have different intentions, their language is inherently less damaging to my blood pressure. > This kind of unprofessional language and attitude would have been > understandable in the 1990's, when Linux was just a really small hobby > project used by only a handful of people. > > It's significantly less understandable today, when Linux is one of the most > if not the most used operating system in the world, used in and by extremely > large institutions and international corporations, and people who contribute > to its kernel code include giant tech megacorporations. > > Just imagine doing business with a giant corporation, and using language > like that. It's astonishingly unprofessional and cringe.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-16 06:02 +0000 |
| Message-ID | <tg13h2$f2g$1@gioia.aioe.org> |
| In reply to | #86339 |
Michael S <already5chosen@yahoo.com> wrote: >> Just read the cringe language used in the *official* Linux kernel coding >> style guideline page: >> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >> > > I like the language of this text. > Style itself - less so; agree or accept with 80%, but not with another 20%. > It seems, what you consider "professional language" I'd consider boring > and bureaucratic. Or, may be, not. In order to know for sure you have to > give me an example of what you consider well-written style guide. An official documentation intended for use by companies and individual people from all around the world, both hobbyists and professionals, from a wide variety of fields of industry, from a wide variety of backgrounds, countries, cultures and customs, *should* be as professional and neutral as possible. It *should* be "boring and bureaucratic". When you write things like "I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture" or "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged [...] No wonder MicroSoft makes buggy programs" the only thing you are doing is alienating people. (And those are just two examples of many.) Also, how many big respectable international corporations would put this kind of language in their official documentation for the wider public? The Linux kernel is not a small hobby project for some small group of nerds anymore. It hasn't been for like a couple decades now. And it isn't even intended to be. The very coding style document itself advocates for the use of Linux (over other OS's like Windows), and clearly would want to be as widely used as possible. Thus, it makes absolutely no sense to use unprofessional cringe and alienating language like that in an official document intended for the wider public. Imagine going to some giant megacorporation to try to sell some idea or product of yours, and in your presentation you used language like that.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-16 10:37 +0000 |
| Message-ID | <tg1jkp$1ggr$1@gioia.aioe.org> |
| In reply to | #86343 |
On Fri, 16 Sep 2022 06:02:12 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Michael S <already5chosen@yahoo.com> wrote: >>> Just read the cringe language used in the *official* Linux kernel coding >>> style guideline page: >>> https://www.kernel.org/doc/html/v4.10/process/coding-style.html >>> >> >> I like the language of this text. >> Style itself - less so; agree or accept with 80%, but not with another 20%. >> It seems, what you consider "professional language" I'd consider boring >> and bureaucratic. Or, may be, not. In order to know for sure you have to >> give me an example of what you consider well-written style guide. > >An official documentation intended for use by companies and individual >people from all around the world, both hobbyists and professionals, >from a wide variety of fields of industry, from a wide variety of >backgrounds, countries, cultures and customs, *should* be as professional >and neutral as possible. It *should* be "boring and bureaucratic". Bollocks. A lot of the people writing linux code are hobbiests and if you want to attract those sorts of people a light hearted approach is a good approach. The LAST thing you want is dull, tedious documentation that drones on to the point where people just stop reading it. >When you write things like > >"I'd suggest printing out a copy of the GNU coding standards, and NOT >read it. Burn them, it's a great symbolic gesture" > >or > >"Encoding the type of a function into the name (so-called Hungarian >notation) is brain damaged [...] No wonder MicroSoft makes buggy programs" > >the only thing you are doing is alienating people. (And those are just You might be alienating some aspies with zero social skills but for most people it'll elicit a chuckle and keep them reading. >two examples of many.) Also, how many big respectable international >corporations would put this kind of language in their official >documentation for the wider public? You're confusing business products with an open source project. One you pay for, one you don't. >The Linux kernel is not a small hobby project for some small group of >nerds anymore. It hasn't been for like a couple decades now. And it >isn't even intended to be. The very coding style document itself Except plenty of people who work on the kernel ARE hobbyists. >advocates for the use of Linux (over other OS's like Windows), and >clearly would want to be as widely used as possible. Thus, it makes >absolutely no sense to use unprofessional cringe and alienating >language like that in an official document intended for the wider >public. > >Imagine going to some giant megacorporation to try to sell some idea >or product of yours, and in your presentation you used language >like that. Oh do bore off.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-16 11:05 +0000 |
| Message-ID | <tg1lac$8t4$1@gioia.aioe.org> |
| In reply to | #86346 |
Muttley@dastardlyhq.com wrote: >>An official documentation intended for use by companies and individual >>people from all around the world, both hobbyists and professionals, >>from a wide variety of fields of industry, from a wide variety of >>backgrounds, countries, cultures and customs, *should* be as professional >>and neutral as possible. It *should* be "boring and bureaucratic". > > Bollocks. A lot of the people writing linux code are hobbiests and if you > want to attract those sorts of people a light hearted approach is a good > approach. The LAST thing you want is dull, tedious documentation that drones > on to the point where people just stop reading it. The majority of current contributors to the Linux kernel are giant international megacorporations (including companies like Intel, Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* the majority of contributors, and haven't been for quite a while. Even then, I have really hard time believing that some hobbyist would decide not to contribute to the Linux kernel because its code style guideline page uses neutral to-the-point professional language. I find the opposite notion to be bizarre and silly. The contrary may well be true: Someone may find the infantile tone of such documentation disgraceful and unprofessional, and dismiss the whole thing as just a toy project. >> Also, how many big respectable international >>corporations would put this kind of language in their official >>documentation for the wider public? > > You're confusing business products with an open source project. One you pay > for, one you don't. This has nothing to do with price. Linux *is* a business project, like it or not. Just because it doesn't cost anything doesn't change that fact. (Tons of corporations have business offering products for free, such as Google, Microsoft and others.) But even if it weren't, using infantile cringle language that's likely to just alienate people makes no sense, no matter how "open source" the project may be. I don't even understand why you are defending that web page. It makes no sense.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-16 13:18 +0000 |
| Message-ID | <tg1t2a$1qb4$1@gioia.aioe.org> |
| In reply to | #86347 |
On Fri, 16 Sep 2022 11:05:50 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Muttley@dastardlyhq.com wrote: >>>An official documentation intended for use by companies and individual >>>people from all around the world, both hobbyists and professionals, >>>from a wide variety of fields of industry, from a wide variety of >>>backgrounds, countries, cultures and customs, *should* be as professional >>>and neutral as possible. It *should* be "boring and bureaucratic". >> >> Bollocks. A lot of the people writing linux code are hobbiests and if you >> want to attract those sorts of people a light hearted approach is a good >> approach. The LAST thing you want is dull, tedious documentation that drones >> on to the point where people just stop reading it. > >The majority of current contributors to the Linux kernel are giant >international megacorporations (including companies like Intel, >Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* >the majority of contributors, and haven't been for quite a while. You'll have some stats to back that up then. >Even then, I have really hard time believing that some hobbyist would >decide not to contribute to the Linux kernel because its code style >guideline page uses neutral to-the-point professional language. I find >the opposite notion to be bizarre and silly. People don't contribute because they have to but because they want to. Even most of the ones employed to do it will have probably started out doing it as a hobby because you don't just hire someone to do kernel development when they've never done it before. >The contrary may well be true: Someone may find the infantile tone of >such documentation disgraceful and unprofessional, and dismiss the whole >thing as just a toy project. Its not infantile, its just tongue in cheek. Plenty of the Dummies Guide books have the same approach and they sell by the bucket load. >>> Also, how many big respectable international >>>corporations would put this kind of language in their official >>>documentation for the wider public? >> >> You're confusing business products with an open source project. One you pay >> for, one you don't. > >This has nothing to do with price. Linux *is* a business project, like The linux kernel which we're discussing is NOT a business project. If a corporation wants to add to it or package it up into a distro and sell that thats up to them, but the kernel is not and never has been a business project. >it or not. Just because it doesn't cost anything doesn't change that >fact. (Tons of corporations have business offering products for free, >such as Google, Microsoft and others.) It value adds what they already have or nudges people into their ecosystem. How does the linux kernel do that? >I don't even understand why you are defending that web page. It makes >no sense. Its clear you have zero sense of humour so there appears to be little point arguing the toss with you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-16 16:00 +0200 |
| Message-ID | <tg1via$3qfgh$1@dont-email.me> |
| In reply to | #86350 |
On 16/09/2022 15:18, Muttley@dastardlyhq.com wrote: > On Fri, 16 Sep 2022 11:05:50 -0000 (UTC) > Juha Nieminen <nospam@thanks.invalid> wrote: >> Muttley@dastardlyhq.com wrote: >>>> An official documentation intended for use by companies and individual >>>> people from all around the world, both hobbyists and professionals, >>> >from a wide variety of fields of industry, from a wide variety of >>>> backgrounds, countries, cultures and customs, *should* be as professional >>>> and neutral as possible. It *should* be "boring and bureaucratic". >>> >>> Bollocks. A lot of the people writing linux code are hobbiests and if you >>> want to attract those sorts of people a light hearted approach is a good >>> approach. The LAST thing you want is dull, tedious documentation that drones >>> on to the point where people just stop reading it. >> >> The majority of current contributors to the Linux kernel are giant >> international megacorporations (including companies like Intel, >> Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* >> the majority of contributors, and haven't been for quite a while. > > You'll have some stats to back that up then. There is a marvellous tool called "google" that can help you avoid making a fool of yourself in public. But to help you out : <https://en.wikipedia.org/wiki/Linux#Community> """ Although Linux distributions are generally available without charge, several large corporations sell, support, and contribute to the development of the components of the system and of free software. An analysis of the Linux kernel in 2017 showed that well over 85% of the code developed by programmers who are being paid for their work, leaving about 8.2% to unpaid developers and 4.1% unclassified.[97] Some of the major corporations that provide contributions include Intel, Samsung, Google, AMD, Oracle and Facebook.[98] A number of corporations, notably Red Hat, Canonical and SUSE, have built a significant business around Linux distributions. """ (I'm sure you are now tempted to make pathetic claims about Wikipedia being wrong - but I'd encourage you to follow the references in the Wikipedia article, and search yourself, before doing so.) <https://lwn.net/Articles/839772/> That puts the number of lines changed for Linux 5.10 at 4% for people contributing without it being via their employer, and 5.3% for "unknown". Thus 90.7% of the changes come from known corporate sources or other employers (such as universities). Other links: <https://www.linux.com/news/who-contributes-linux-kernel/> (I've snipped the rest of your post, since you are writing out of complete ignorance or denial about Linux. Ignorance is easily cured, if you are willing to accept the cure - read the links, and research yourself for more information that is wildly off-topic for this group.) >> I don't even understand why you are defending that web page. It makes >> no sense. > > Its clear you have zero sense of humour so there appears to be little point > arguing the toss with you. > I can't answer for Juha's sense of humour, but he is spot-on about how and by whom Linux is developed and how the development is paid for, and how it is a professional project. And I suspect he is well aware of the difference between "light-hearted with a bit of humour" and the language used in the kernel style guide. College student level jokes are fine between college students - they are inappropriate for a professional and serious project.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-16 15:16 +0000 |
| Message-ID | <tg2411$1cps$1@gioia.aioe.org> |
| In reply to | #86353 |
On Fri, 16 Sep 2022 16:00:41 +0200 David Brown <david.brown@hesbynett.no> wrote: >On 16/09/2022 15:18, Muttley@dastardlyhq.com wrote: >> On Fri, 16 Sep 2022 11:05:50 -0000 (UTC) >> Juha Nieminen <nospam@thanks.invalid> wrote: >>> Muttley@dastardlyhq.com wrote: >>>>> An official documentation intended for use by companies and individual >>>>> people from all around the world, both hobbyists and professionals, >>>> >from a wide variety of fields of industry, from a wide variety of >>>>> backgrounds, countries, cultures and customs, *should* be as professional >>>>> and neutral as possible. It *should* be "boring and bureaucratic". >>>> >>>> Bollocks. A lot of the people writing linux code are hobbiests and if you >>>> want to attract those sorts of people a light hearted approach is a good >>>> approach. The LAST thing you want is dull, tedious documentation that >drones >>>> on to the point where people just stop reading it. >>> >>> The majority of current contributors to the Linux kernel are giant >>> international megacorporations (including companies like Intel, >>> Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* >>> the majority of contributors, and haven't been for quite a while. >> >> You'll have some stats to back that up then. > >There is a marvellous tool called "google" that can help you avoid >making a fool of yourself in public. But to help you out : Thanks for that, never thought of it. >That puts the number of lines changed for Linux 5.10 at 4% for people >contributing without it being via their employer, and 5.3% for >"unknown". Thus 90.7% of the changes come from known corporate sources >or other employers (such as universities). Thats not the same as 90% in total over the decades. I suspect its rather smaller. >>> I don't even understand why you are defending that web page. It makes >>> no sense. >> >> Its clear you have zero sense of humour so there appears to be little point >> arguing the toss with you. >> > >I can't answer for Juha's sense of humour, but he is spot-on about how >and by whom Linux is developed and how the development is paid for, and >how it is a professional project. And I suspect he is well aware of the >difference between "light-hearted with a bit of humour" and the language >used in the kernel style guide. College student level jokes are fine >between college students - they are inappropriate for a professional and >serious project. Both you and Juha are humourless bores and in your case one who takes himself far too seriously. People who cling on to professionalism as some kind of badge are usually making up for a lack of actual skills.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-18 12:13 +0200 |
| Message-ID | <tg6r0v$figc$1@dont-email.me> |
| In reply to | #86357 |
On 16/09/2022 17:16, Muttley@dastardlyhq.com wrote: > On Fri, 16 Sep 2022 16:00:41 +0200 > David Brown <david.brown@hesbynett.no> wrote: >> On 16/09/2022 15:18, Muttley@dastardlyhq.com wrote: >>> On Fri, 16 Sep 2022 11:05:50 -0000 (UTC) >>> Juha Nieminen <nospam@thanks.invalid> wrote: >>>> Muttley@dastardlyhq.com wrote: >>>>>> An official documentation intended for use by companies and individual >>>>>> people from all around the world, both hobbyists and professionals, >>>>> >from a wide variety of fields of industry, from a wide variety of >>>>>> backgrounds, countries, cultures and customs, *should* be as professional >>>>>> and neutral as possible. It *should* be "boring and bureaucratic". >>>>> >>>>> Bollocks. A lot of the people writing linux code are hobbiests and if you >>>>> want to attract those sorts of people a light hearted approach is a good >>>>> approach. The LAST thing you want is dull, tedious documentation that >> drones >>>>> on to the point where people just stop reading it. >>>> >>>> The majority of current contributors to the Linux kernel are giant >>>> international megacorporations (including companies like Intel, >>>> Google, Huawei, Red Hat, Linaro, Samsung and IBM). Hobbyists are *not* >>>> the majority of contributors, and haven't been for quite a while. >>> >>> You'll have some stats to back that up then. >> >> There is a marvellous tool called "google" that can help you avoid >> making a fool of yourself in public. But to help you out : > > Thanks for that, never thought of it. > >> That puts the number of lines changed for Linux 5.10 at 4% for people >> contributing without it being via their employer, and 5.3% for >> "unknown". Thus 90.7% of the changes come from known corporate sources >> or other employers (such as universities). > > Thats not the same as 90% in total over the decades. I suspect its rather > smaller. Since you claim to be familiar with Google, I'll let you do your own research here into how long Linux development contributions have been dominated by people paid to do the work - including how long Linus Torvalds has been paid for his efforts. You might also look at how the lines of code in the kernel have grown, and then you can get an idea of how much of the kernel is written by people paid by their employers to do the work. It is probably smaller than 90%, since that is the figure for the changes to Linux 5.10. (Actually, the figure is 90% to 95% - unknown is unknown.) It would be very difficult to establish a true figure for the total of the kernel source as it is now, as parts have been re-written or replaced many times. But I think there is little doubt that it is made primarily by people who are paid to do the work. (The same applies to many other major open source projects, such as gcc and clang.) > >>>> I don't even understand why you are defending that web page. It makes >>>> no sense. >>> >>> Its clear you have zero sense of humour so there appears to be little point >>> arguing the toss with you. >>> >> >> I can't answer for Juha's sense of humour, but he is spot-on about how >> and by whom Linux is developed and how the development is paid for, and >> how it is a professional project. And I suspect he is well aware of the >> difference between "light-hearted with a bit of humour" and the language >> used in the kernel style guide. College student level jokes are fine >> between college students - they are inappropriate for a professional and >> serious project. > > Both you and Juha are humourless bores and in your case one who takes himself > far too seriously. People who cling on to professionalism as some kind of > badge are usually making up for a lack of actual skills. > People who can't distinguish between serious, professional work (or indeed serious amateur work) and overgrown teenager attitudes are a bane to society. Documents like that guide are not light-hearted or entertaining in a workplace - they are an embarrassment. It's fine to post that kind of humour as a joke, but not as a requirement for real work.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web