Samsung would never become Tizen-only shop. They would go on making all possible devices, Android and WinPho included.
Otherwise, Nokia lost its #1 position because they have failed to adapt their devices to new markets. That is precisely what Samsung tries to avoid with the Tizen. Since there is no Google to set the rules what can and cannot be an Android device and OS, Samsung (and others) can tweak Tizen to fit pretty much any device they like. After all, Tizen is larger than Samsung and is not exclusively a phone OS.
How much an Android device is worth without the Google Play store? Not much.
If you disable all the accounts/etc, pure Samsung device wins hands down over the Google one, because most Google apps these days are crap. While Samsung's apps for the most part try to be simply useful.
And if you wish to have the up-to-date with the Android version, the Google account and oftentimes G+ account are strongly suggested. Because occasionally Google forgets that not everybody is a Google/G+ user and in absence of the account some basic features simply do not work. That was experience of some of my friends who updated their Galaxies to the Lollipop, only to find that some stuff simply doesn't work because they are do not have the G+ account.
I think generic programming is destined to be second class citizen. IMO the human side of the problem is not the biggest out.
The biggest one is that there is no compiler which can untangle such code and generate something efficient out of it.
This is basically the attic where all the "everything is an object" languages have stuck. On one side, development is made easier in many places because everything is an object. On the other side, the performance and memory consumption degrade, to the point where developers end up counting and optimizing object usage of every code line and function. Because there are no compilers which are capable of deducing from the human readable code what the hell developer actually wanted to accomplish.
That brings me to the other bigger issue. Most concepts and paradigm, including the generic programming, which occupy the minds of researchers do NOT help solve the ultimate problem of the computer programming: efficiently communicating with the CPU, efficiently telling it what needs to be done.
If developer is a writer, CPU is a reader, and assembler is the spoken language, then most simple programs, with 10-50K instructions, are close the novel size. Think of it: the usual "Hello World" program, to a CPU is close in size to the novel! And if it's in an interpreted language, the CPU might end up reading a whole frigging roman, just to deduce that all what developer wanted was to print the "Hello World" on screen.
Everybody has already settled on the little-endian presentation.
What makes you think this? There are plenty of old Motorola architecture based systems still in legacy environment use, preserved for stable scientific or business computing environments.
Man, I come from the BE world. You do not need to tell me that there is still abundance of the BE hardware.
And there is a significant amount of new, bi-endian hardware being produced now,
Most modern CPUs I had to deal with, except the Intel, are bi-endian. BUT. Most (by model number) are used in BE mode. (But since ARM also has settled on the LE, now it is effectively a LE world.)
Yet.
1st. The endianness of the CPU is not related to the endianness of an data exchange format.
2ns. The endianness of the data exchange format does not relate to the internal presentation of the data in the application's memory.
I'm afraid I have quite a lot of experience with Unicode compatibility and cross compatibility. Frankly, for a multi-platform tool like Nethack, I'd stay with the 8-bit, one byte, extremely stable 'POSIX' standard.
You folks lump it all together. There are two sides to it: internal presentation and external conversion.
For internal presentation, one goes with whatever makes your life as developer easier. UCS-4 is definitively an option. UTF-8 (aka "I do not care, just passing data through") is also OK. Most applications fall into the later category. But if one ever starts pondering use of the widechars, when one needs to actually peek at the data, then there is simply no point using the UTF-16. And UTF-8 has disadvantages whne .
For external conversions, all what matters that the internal format can be easily converted into the widely used encodings. Application doesn't have any direct control over it - it is user controlled. User might pick UTF-8. Or JIS. Or win-1257. And application has to make sure that when it spews the data to outside, they come out in the encoding requested by the user.
Naive notion of that utf-8 is used by everybody is extremely naive. And IMO it is rooted in the same arrogance which held back the *nix world for decades in the dark ages of the 7-bit ASCII.
Characters in Thai are rendered in display-oredr, and not logical order. [...]
Ha! Not relevant to me, actually. But very informative. Thanks.
Overall, most customers are aware of the problems (and in my experience better than me). Simple handling I had in my software had worked and was sufficient.
The Thai language specifically is a cool example. Why not relevant? My company refused to do Thai localization. (And thanks to you now I know fully why.) To do the localization we were told that we have to buy a special Thai language library. The library costs huge money. When we told customer that they would have to pay for it, they have refused and canceled the project, because for them it was too too expensive.
So basically what you (and others) are saying, is that since there are some edge cases foreseen in the standard, nobody should try to make life easier even by a bit?
Combining characters (and the rest of the crap) pretty much never occur in real life. Only in some sadistic test case for the Unicode libraries, probably.
The main purpose of Unicode, why both users and developers want it, is to represent as much as characters as possible with least hustle possible. And that's pretty much what everybody's shooting for.
i don't see a real argument here. "considering the length". how long is it?
Check the game history. Literally decades between major releases.
"some of the silliness". what silliness is this exactly? external storage of utf-32 requires that one
deal with an endian character set. every time any text is touched, you'll get to endian convert.
Everybody has already settled on the little-endian presentation.
isn't that awesome? utf-8 does not have this issue. and one can almost always treat utf8 as a
byte stream. except in the rare case where one needs to know where character boundaries are.
for example, to map the character to a font. the fast path is the common path (ascii), and just requires
a single test ((c&0x80) == 0).
With UCS-4 you do not even need any tests.
Extracting a character - trivial.
Length of string - trivial.
Normalization - much simpler than the utf-8.
The sad reality that libraries I have seen actually implement the utf-8 handling by using internally utf-32. You can't avoid it: Unicode is specified in the code points, which as you point it out are already as good as 32 bit long.
sure the gnu c library has had bad wchar_t conversion routines in the past, but it's a free
country. you can implement your own.
Frankly, I haven't even used C library for the purpose. We had already one library developed in-house, because portable support for utf-8 is patchy at best.
The sanest portable approach is to link with iconv and convert everything from some internal presentation to external. Because you can never know what encoding user needs. Unless you really need to save the RAM (one has shitload of string data), utf-8 simply sucks as internal presentation.
P.S. I have had very little experience with Unicode. But several month of dealing with it, have simply convinced me that if one has to deal with l10n/i10n, then utf-16/utf-32 are very good choices. Ditto, if one has to deal with the Unicode. If application really doesn't care what it prints or reads - then pass-through binary (utf-8) works too. But as soon as one has to take the length of utf-8 string (real length), then it is time to start switching from utf-8 to utf-32.
It would helped if you have specified the workloads you are after.
Otherwise, laptops with best termal control I have seen were HP and Apple. But those, again, are laptops, not a slim portable servers. Laptops will always suck at this, because they are, duh, laptops: they are designed to be portable, not being capable of dissipating >300W of waste heat. They are also designed not to burn wholes in your pants, if you per chance would decide to put the laptop on your, well, lap.
I have personally in the past used a plain PC tower as a compile farm for software development. The laptop was old (very old) and compiling anything large-ish on it was a huge chore (and waste of time). I have configured the distcc to simply run all compilation of the PC instead. Work and compile in the quiet of the bedroom, while noisy and hot PC, compiling stuff full time on its four cores, stays in the guest room.
For as long as one is OK giving up some of the credit to the ass kissers, it can be made work.
The real problem are extroverts who are not yet promoted, or worse: those who believe that they are great coders. (As you can see, they are very humble: they are not "extraordinary" - just "great".)
For as long as your lower ranks are made up of reliable people, the introverts can steer the company any way they want, because they are the people who do the actual work.
And extroverts have rather short attention span.
When I say, "A is not possible, but B is", they basically have no chance of opposing me. If they insist on going with A, I can still do B and later say that it is what they have asked. Chances are that they are already on the next big thing and do not care about the "past".
Docker's report that a downloaded image is 'verified' is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest.
Can it be enabled? If yes, then I do not see a problem.
Otherwise, the signing crap is just that: crap.
It takes needlessly long time to verify the signature. (Because they are not slow! - they are so secure, so very much OMG secure.)
It is a huge risk to reconfigure a production system to use unsigned data if emergency arises. (Think recovery from a local backup.)
Developers forget to renew their certificates and suddenly, in the middle of a production, whole system goes down, because OMG the certificate has expired and data may be not secure!!!
And then, in the end, the signing keys get leaked or stolen...
No. Gnome demands libpam-systemd or consolekit. libpam-systemd demands either systemd or systemd-shim.
So either work on consolekit/consolekit2 or work on systemd-shim.
I was basically quoting Debian's GNOME maintainer, from the times of the Debian's CTTE debate.
At least at the time, Debian's GNOME package had a hardcoded dependency on the systemd package, not a feature/virtual package which provides the services. And GNOME DDs were refusing to change that, because they didn't like the systemd-shim.
And this is a clear systemd bias (and GNOME attitude).
If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?
The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.
The whole problem of the hairy rcS scripts was ability to workaround pretty much any software or hardware problem on spot. Here, systemd insists that they are always in right - it is the rest of the world who are wrong. The problem is that a blank statement about wrongness of the world (it never was right to begin with) doesn't solve the immediate problem users are having.
I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.
Frankly I do not remember. It could have been one of the adjacent tickets about the systemd breaking the systems on autoupdate.
Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)
Huh?
If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.
That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.
Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.
I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.
Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.
If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.
You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.
Hu?
This very topic was laundered during the init system selection on the debian-ctte for very long time: it makes no sense to invest time into developing systemd if upstart is picked, and vice versa.
There might be people willing to do the work - but there is little more demotivational than a project declaring that they are taking a different path.
But the most demotivational is when people are told that they can't even have an alternative systemd implementation/fork - of which there are already couple - because GNOME demands the systemd, not just any systemd.
For motivation to spend your free time on something, this is as good as hitting a brick wall at full speed.
The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.
To me the most interesting part whether the whole fork would even take off.
Technical aspects of init system replacement are very easy - compared to the establishment of an organizational structure of the Debian.
I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.
The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.
One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".
That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.
The larger question is: what Devuan is really forking?
Do they fork a distro?
Or do they fork an organization?
With some work, one can fork a distro. But to fork the organization, one need to win over the people. I doubt that they will win over many (Debian) people without actually changing something in the forked organization.
Though many see the "systemd vs world" as the dividing force, in reality there is IMO problem with Debian organization. I have followed the debate for some time, and IMO, the problem is that there is too much democracy in the Debian. Public debate is a good thing. But too much of it simply prevents the organization from doing its work. That is IMO what has happened during the Debian's init system selection process.
There is a unicode character known as a soft hyphen. The soft hyphen indicates where to break a word if it doesn't all fit on a line. This character should be used instead of a hard hyphen most of the time.
Too bad eBook readers are very inconsistent in their support for that. Some readers display an icon indicating an unknown glyph, many fail to insert the hyphen....
Alas.
That soft hyphen would have been a blessing for the German e-books. Some texts are flush with the overly long words, making them very hard to read.
But Kindle (last time I checked) doesn't support it.
Neither the Calibre and few other e-book viewers/editors I have tried in the past.
In other words, in my experience the support is uniform and consistent: no support whatsoever, sadly.
P.S. On top of it, the Kindle devices I have, also have the rendering and text selection bugs when displaying/selecting the text around words (even if they are hyphenated) which are longer than the single visible line.
Slashdot Mirror
The fact is hasn't been on any significant number of devices in the real world would be a big flag, [...]
There is a significant number of Tizen devices in the real world. Several car manufacturers use it for IVI (in-vehicle infotainment) systems.
[...] there's alot of refinement that comes from *actual* use in the wild that you don't get from lab development.
MS Windows? G+? Refinement from the actual use in the wild: zero.
Samsung would never become Tizen-only shop. They would go on making all possible devices, Android and WinPho included.
Otherwise, Nokia lost its #1 position because they have failed to adapt their devices to new markets. That is precisely what Samsung tries to avoid with the Tizen. Since there is no Google to set the rules what can and cannot be an Android device and OS, Samsung (and others) can tweak Tizen to fit pretty much any device they like. After all, Tizen is larger than Samsung and is not exclusively a phone OS.
How much an Android device is worth without the Google Play store? Not much.
If you disable all the accounts/etc, pure Samsung device wins hands down over the Google one, because most Google apps these days are crap. While Samsung's apps for the most part try to be simply useful.
And if you wish to have the up-to-date with the Android version, the Google account and oftentimes G+ account are strongly suggested. Because occasionally Google forgets that not everybody is a Google/G+ user and in absence of the account some basic features simply do not work. That was experience of some of my friends who updated their Galaxies to the Lollipop, only to find that some stuff simply doesn't work because they are do not have the G+ account.
I think generic programming is destined to be second class citizen. IMO the human side of the problem is not the biggest out.
The biggest one is that there is no compiler which can untangle such code and generate something efficient out of it.
This is basically the attic where all the "everything is an object" languages have stuck. On one side, development is made easier in many places because everything is an object. On the other side, the performance and memory consumption degrade, to the point where developers end up counting and optimizing object usage of every code line and function. Because there are no compilers which are capable of deducing from the human readable code what the hell developer actually wanted to accomplish.
That brings me to the other bigger issue. Most concepts and paradigm, including the generic programming, which occupy the minds of researchers do NOT help solve the ultimate problem of the computer programming: efficiently communicating with the CPU, efficiently telling it what needs to be done.
If developer is a writer, CPU is a reader, and assembler is the spoken language, then most simple programs, with 10-50K instructions, are close the novel size. Think of it: the usual "Hello World" program, to a CPU is close in size to the novel! And if it's in an interpreted language, the CPU might end up reading a whole frigging roman, just to deduce that all what developer wanted was to print the "Hello World" on screen.
Everybody has already settled on the little-endian presentation.
What makes you think this? There are plenty of old Motorola architecture based systems still in legacy environment use, preserved for stable scientific or business computing environments.
Man, I come from the BE world. You do not need to tell me that there is still abundance of the BE hardware.
And there is a significant amount of new, bi-endian hardware being produced now,
Most modern CPUs I had to deal with, except the Intel, are bi-endian. BUT. Most (by model number) are used in BE mode. (But since ARM also has settled on the LE, now it is effectively a LE world.)
Yet.
1st. The endianness of the CPU is not related to the endianness of an data exchange format.
2ns. The endianness of the data exchange format does not relate to the internal presentation of the data in the application's memory.
I'm afraid I have quite a lot of experience with Unicode compatibility and cross compatibility. Frankly, for a multi-platform tool like Nethack, I'd stay with the 8-bit, one byte, extremely stable 'POSIX' standard.
You folks lump it all together. There are two sides to it: internal presentation and external conversion.
For internal presentation, one goes with whatever makes your life as developer easier. UCS-4 is definitively an option. UTF-8 (aka "I do not care, just passing data through") is also OK. Most applications fall into the later category. But if one ever starts pondering use of the widechars, when one needs to actually peek at the data, then there is simply no point using the UTF-16. And UTF-8 has disadvantages whne .
For external conversions, all what matters that the internal format can be easily converted into the widely used encodings. Application doesn't have any direct control over it - it is user controlled. User might pick UTF-8. Or JIS. Or win-1257. And application has to make sure that when it spews the data to outside, they come out in the encoding requested by the user.
Naive notion of that utf-8 is used by everybody is extremely naive. And IMO it is rooted in the same arrogance which held back the *nix world for decades in the dark ages of the 7-bit ASCII.
So what you propose?
Go with utf-8 which doesn't alleviate any of the problems? But adds its own one?
Beside, I doubt very much that anybody is going to use any of the fancy characters in the NetHack.
Characters in Thai are rendered in display-oredr, and not logical order. [...]
Ha! Not relevant to me, actually. But very informative. Thanks.
Overall, most customers are aware of the problems (and in my experience better than me). Simple handling I had in my software had worked and was sufficient.
The Thai language specifically is a cool example. Why not relevant? My company refused to do Thai localization. (And thanks to you now I know fully why.) To do the localization we were told that we have to buy a special Thai language library. The library costs huge money. When we told customer that they would have to pay for it, they have refused and canceled the project, because for them it was too too expensive.
So basically what you (and others) are saying, is that since there are some edge cases foreseen in the standard, nobody should try to make life easier even by a bit?
Combining characters (and the rest of the crap) pretty much never occur in real life. Only in some sadistic test case for the Unicode libraries, probably.
The main purpose of Unicode, why both users and developers want it, is to represent as much as characters as possible with least hustle possible. And that's pretty much what everybody's shooting for.
Its obvious you have little real experience with unicode, because saying 'just convert to utf-32' just papers over the problems without solving them.
Indeed I've only scratched surface. And that alone gave me headaches for months.
UTF-32 units are code points, not characters, and there are many multi-code-point (variable length) characters in utf-32.
For example?
It is the same problem as with the fancy acute/agrave/etc special symbols.
And the special white-space/no-space characters. And the special writing direction change characters.
They are generally removed during normalization/conversion into canonical presentation.
The thing is, after the normalization, which is needed for any Unicode text anyway, UCS-4 becomes a plain array of characters. But UTF-8 - still not.
i don't see a real argument here. "considering the length". how long is it?
Check the game history. Literally decades between major releases.
"some of the silliness". what silliness is this exactly? external storage of utf-32 requires that one deal with an endian character set. every time any text is touched, you'll get to endian convert.
Everybody has already settled on the little-endian presentation.
isn't that awesome? utf-8 does not have this issue. and one can almost always treat utf8 as a byte stream. except in the rare case where one needs to know where character boundaries are. for example, to map the character to a font. the fast path is the common path (ascii), and just requires a single test ((c&0x80) == 0).
With UCS-4 you do not even need any tests.
Extracting a character - trivial.
Length of string - trivial.
Normalization - much simpler than the utf-8.
The sad reality that libraries I have seen actually implement the utf-8 handling by using internally utf-32. You can't avoid it: Unicode is specified in the code points, which as you point it out are already as good as 32 bit long.
sure the gnu c library has had bad wchar_t conversion routines in the past, but it's a free country. you can implement your own.
Frankly, I haven't even used C library for the purpose. We had already one library developed in-house, because portable support for utf-8 is patchy at best.
The sanest portable approach is to link with iconv and convert everything from some internal presentation to external. Because you can never know what encoding user needs. Unless you really need to save the RAM (one has shitload of string data), utf-8 simply sucks as internal presentation.
P.S. I have had very little experience with Unicode. But several month of dealing with it, have simply convinced me that if one has to deal with l10n/i10n, then utf-16/utf-32 are very good choices. Ditto, if one has to deal with the Unicode. If application really doesn't care what it prints or reads - then pass-through binary (utf-8) works too. But as soon as one has to take the length of utf-8 string (real length), then it is time to start switching from utf-8 to utf-32.
Considering the length of their release cycle, seems to be a safe choice.
It's not like the difference 1/2/4 bytes would make much performance difference for the application like NetHack.
Using the utf-32 internally would save them from some of the silliness the alternatives like utf-8 bring with them.
Gee, money does grow on trees.
Since some money are actually made of actual paper, this is a factually correct statement!
Tax payers can afford to pay for lazy asses to never enter the work force by continuing education for a life time.
Two years is a life time?
Let me guess: you are from red neck state with life expectancy under 35?
And while we are at it, why not free cable?
One can succeed in life without the cable. But not without the education.
Or perhaps free condoms?
Actually some school and medical institutions already give away free condoms.
And it's only 3.6GHz!
I LOLed.
It would helped if you have specified the workloads you are after.
Otherwise, laptops with best termal control I have seen were HP and Apple. But those, again, are laptops, not a slim portable servers. Laptops will always suck at this, because they are, duh, laptops: they are designed to be portable, not being capable of dissipating >300W of waste heat. They are also designed not to burn wholes in your pants, if you per chance would decide to put the laptop on your, well, lap.
I have personally in the past used a plain PC tower as a compile farm for software development. The laptop was old (very old) and compiling anything large-ish on it was a huge chore (and waste of time). I have configured the distcc to simply run all compilation of the PC instead. Work and compile in the quiet of the bedroom, while noisy and hot PC, compiling stuff full time on its four cores, stays in the guest room.
Bummer, eh?
For as long as one is OK giving up some of the credit to the ass kissers, it can be made work.
The real problem are extroverts who are not yet promoted, or worse: those who believe that they are great coders. (As you can see, they are very humble: they are not "extraordinary" - just "great".)
For as long as your lower ranks are made up of reliable people, the introverts can steer the company any way they want, because they are the people who do the actual work.
And extroverts have rather short attention span.
When I say, "A is not possible, but B is", they basically have no chance of opposing me. If they insist on going with A, I can still do B and later say that it is what they have asked. Chances are that they are already on the next big thing and do not care about the "past".
Eliminating space program would mean that lots of R&D wouldn't be done anymore (domestically).
That's a dangerous gamble.
USA should trim the military budget first.
Wear Leveling?
Leakage Leveling?
P.S. Question is whether a workaround is possible with the CPU microcode.
Docker's report that a downloaded image is 'verified' is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest.
Can it be enabled? If yes, then I do not see a problem.
Otherwise, the signing crap is just that: crap.
It takes needlessly long time to verify the signature. (Because they are not slow! - they are so secure, so very much OMG secure.)
It is a huge risk to reconfigure a production system to use unsigned data if emergency arises. (Think recovery from a local backup.)
Developers forget to renew their certificates and suddenly, in the middle of a production, whole system goes down, because OMG the certificate has expired and data may be not secure!!!
And then, in the end, the signing keys get leaked or stolen...
GNOME demands the systemd, not just any systemd.
No. Gnome demands libpam-systemd or consolekit. libpam-systemd demands either systemd or systemd-shim.
So either work on consolekit/consolekit2 or work on systemd-shim.
I was basically quoting Debian's GNOME maintainer, from the times of the Debian's CTTE debate.
At least at the time, Debian's GNOME package had a hardcoded dependency on the systemd package, not a feature/virtual package which provides the services. And GNOME DDs were refusing to change that, because they didn't like the systemd-shim.
If it isn't a bug, why patch it?
And this is a clear systemd bias (and GNOME attitude).
If systemd says it is not a bug, then it is not. And if something doesn't work - well, somebody opened a ticket about something NOT working - then something does NOT work. And if the systemd refused to fix it - who's going to?
The whole position of systemd implementors in Debian was and probably still is: we change how the whole system works, but we are totally not responsible if something breaks, because it is, duh, mainline systemd.
The whole problem of the hairy rcS scripts was ability to workaround pretty much any software or hardware problem on spot. Here, systemd insists that they are always in right - it is the rest of the world who are wrong. The problem is that a blank statement about wrongness of the world (it never was right to begin with) doesn't solve the immediate problem users are having.
I have actually read most of them at the time, and I still think you are misrepresenting the systemd maintainers.
Frankly I do not remember. It could have been one of the adjacent tickets about the systemd breaking the systems on autoupdate.
Tollef Fog Heen was pretty clear that he is not going to do anything special for Debian. (He is (or was at the time) a Fedora user already anyway.)
Huh?
If you can't tell what the hell the trivial commit does, then you are obviously not a software developer.
That was a great PR move on part of the systemd developers: to flood the mail lists with the buzz words. Users have no idea what they mean - but they sure sound cool - so systemd must be cool too.
Sure, the main branch of systemd wants to have as few distro specific patches as possible, but they do accept them if there is no other solution.
I was just quoting the (ex-)maintainer of the systemd, from his e-mails from the CTTE discussion.
Debian feedback would be submitted to mainline - but if it is rejected, he wouldn't even carry a custom Debian patch for it, because he doesn't want to deviate from the mainline. And he, as the maintainer of the systemd, would not consider it a bug. As such somebody else would have to fix somewhere else.
If you are willing to grep through the 1K emails - you would definitely find that being repeated several time.
Here is a Debian specific patch that predates Debians adoption of systemd as default init-system: http://cgit.freedesktop.org/sy...
It's obviously not Debian specific.
It is very obviously a distro specific part of systemd: Debian was added to the list where Fedora and Arch were already present.
You're talking about Debian and Devuan like it's two monolithic organizations. It's not. It's people. And and if you want "Debian" to do something then real human Debian developers will have to do the job. It doesn't matter what any committee decides if no one is interested in actually doing the work.
Hu?
This very topic was laundered during the init system selection on the debian-ctte for very long time: it makes no sense to invest time into developing systemd if upstart is picked, and vice versa.
There might be people willing to do the work - but there is little more demotivational than a project declaring that they are taking a different path.
But the most demotivational is when people are told that they can't even have an alternative systemd implementation/fork - of which there are already couple - because GNOME demands the systemd, not just any systemd.
For motivation to spend your free time on something, this is as good as hitting a brick wall at full speed.
The Devuan developers are obviously up for the task. That's great. They do what they want to do. It's just too bad that they for whatever reason couldn't do it in Debian. I don't blame them. It takes an arm and a leg to get into Debian nowdays, so if it's easier for them to create a fork then maybe that says something about the Debian project too.
To me the most interesting part whether the whole fork would even take off.
Technical aspects of init system replacement are very easy - compared to the establishment of an organizational structure of the Debian.
I do not know the answer for the Debian, but if you did RTFA, you would notice that it is precisely what the Devuan is doing: creating and packaging software which provide the interface of systemd services without the systemd itself.
The (retorical) question which I have already asked on difference occasions here is whether the Debian is a good place to do such development.
One strong undertone from the CTTE's init system selection debate was that Debian doesn't want to do the development and wants to maximize the reuse of the code from the other distros. This turned into a weird attitude when systemd vs. upstart was evaluated. The upstart devs and maintainers have committed themselves to implement whatever Debian needs. The systemd devs and maintainers committed to literally to nothing, basically saying "if it is good for Fedora is should do the job for Debian too; no Debian specific patches are going to be accepted even into the Debian systemd package". And that was later respun by a couple of CTTE members as "upstart still needs development while systemd doesn't".
That is also why I raise the question about changes to the Debian organization in Devuan: How could Devuan be more software developer friendlier? At the moment the barrier to entry is very high, leaving developers at mercy of the respective Debian packager. Or leaving the developer basically out if it has something to do with the low-level stuff like init system.
The larger question is: what Devuan is really forking?
Do they fork a distro?
Or do they fork an organization?
With some work, one can fork a distro. But to fork the organization, one need to win over the people. I doubt that they will win over many (Debian) people without actually changing something in the forked organization.
Though many see the "systemd vs world" as the dividing force, in reality there is IMO problem with Debian organization. I have followed the debate for some time, and IMO, the problem is that there is too much democracy in the Debian. Public debate is a good thing. But too much of it simply prevents the organization from doing its work. That is IMO what has happened during the Debian's init system selection process.
Too bad eBook readers are very inconsistent in their support for that. Some readers display an icon indicating an unknown glyph, many fail to insert the hyphen....
Alas.
That soft hyphen would have been a blessing for the German e-books. Some texts are flush with the overly long words, making them very hard to read.
But Kindle (last time I checked) doesn't support it.
Neither the Calibre and few other e-book viewers/editors I have tried in the past.
In other words, in my experience the support is uniform and consistent: no support whatsoever, sadly.
P.S. On top of it, the Kindle devices I have, also have the rendering and text selection bugs when displaying/selecting the text around words (even if they are hyphenated) which are longer than the single visible line.