I mean, not list of all options and files in alphabetical orders with brief explanations what each does to another obscure file without giving any clue WHY and WHAT FOR, and why should I care. I want a guide, starting with overview of the logic, structure and purpose of main components, what are the purposes and tasks of systemd, how it achieves them, and how to control and modify them, in that order.
Currently, I found only two types of systemd docs: "inventory/catalogue of options", something an already proficient systemd developer could use as reference to recall finer details of given functions, and "voodoo programming" guides. Want A: Type X, press Y, enter Z. Something for a total newbie, to get given thing done and remain none the wiser. I'm yet to find something that allows one to "enter the world of systemd", and start understanding it.
Well, we don't happen to have money to hire a database designer, to invent the SQL queries that would do what 20 lines of Perl over JSON file can do.
Actually, we do use the relational database, except for the most wildly varying entries, there's a text field, which contains the JSON objects. I mean, if the field "measurement" may be an int, a float, an enum, an array, an array of arrays of variable length, containing int, float, NULL or NaN, or a structure composed of a string and three booleans, yeah, that can be normalized into a bunch of tables, and queries for these can be written, but... seriously, why?
"If I write this program in an easily extensible way, expanding this later will be a breeze."
Lots of classes, rich inheritance trees, broad project on top of a robust framework, making adding extra modules fairly easy. Your program is clean, well-documented, and has a logical structure, all according to best practices. It's also about 4 times bigger than it would really need to be, it takes 3 times as much RAM (primarily due to loading all the neat frameworks and libraries that you used "not to reinvent the wheel" even if you only use one or two simple functions from these), but who cares, this is the modern paradigm, and everything is automated and works so smoothly you can be nothing but proud of it. Now just to support it, fix some bugs, and implement extra features.
Then the new requirements arrive, you look at the email, you look at the top level schematics of your system and you realize, with a sinking feeling, that you never imagined the system would need to be expanded *that* way. And that this particular framework doesn't support this approach, and never will, because its authors decided they never plan to support it, or that the target platform doesn't support, and can't ever support the kind of libraries you use, or that you currently depend on a piece of hardware to do a job which you will need to write from scratch, or the new legal requirements (which are not disputable; new law says so) go completely against your system philosophy, which provides equivalent but completely different functionality, or the essential library just has been discontinued, and new security holes have been found in it...
Or at the very least, you realize that a feature that amounts to ten lines of code performing a really simple tricks requires you to create ten different files, two thousand lines of code, config and extras, and modification of several existing files, because the way the extensions of this type are applicable is writing a plugin which is a separate project with a whole non-trivial instantiation of framework, build system, security, and compatibility with your smart dynamic plugin loading mechanism. What would amount to pasting a 12-line function called once per tick from the main loop, amounts to a three-week project building the plugin/wrapper for that 10-line snippet.
You CAN NOT foresee future requirements. You CAN NOT plan all possible future extensions ahead of time. And the more you plan for, the more "flexible" you try to be, the larger and more rigid your project becomes in areas you failed to foresee, and the harder it will be to adapt it for these.
Yes, leave hooks for stuff you have it on a good authority WILL happen. Do not try to plan for every eventuality though. Write good clean code that does what it's meant to do, and doesn't try to be ready for anything else. It will be *easier* to expand once the time comes.
Ubuntu has a very solid backend/engine, but the frontend has been dumbed down to the level of a Fisher Prize toy.
It's a decent way to get started with Linux from zero, and a good thing for people who are computer-illiterate, but if one day you get tired with Ubuntu behaving like an overprotective mother of a 3-year-old (with you being the 3-year-old), just sudo apt install kubuntu-desktop to get a reasonable frontend replacement.
It seems it's not active throttling, just fallback to failsafe set of features; it's not the issue of specifically "Firefox+Linux", it's the general "Other".
Instead of feature detection, they sniff the UA string and upon failing to find a "supported browser" serve code for "unsupported" which is woefully unoptimal.
Oh, the IDE can only go so far. It helps, but once you have the relevant logic spread over 20 or more files, no IDE will let you grasp it all.
I tried following what "smarter people" created before me. Preparing for every possible eventual expansion of the system - adding new business logic algorithms, new types of input data, new variants of output, dynamic switch of dataset and algorithm mid-execution, massive parallelism, with a lot of cross-thread communication and clever automatic scheduling of tasks. They had been mucking around with it for 3 years, making a system that was very elegant - and completely useless.
It appeared the underlying system requires everything to be single thread, running under RTOS, because critical operations were not being completed on time and race conditions resulting from the underlying system design abound. And the deadline was in half a year.
All that fancy work had to be scrapped and written from scratch, in a much simplified form only sparsely utilizing scraps of old logic. The whole fancy broad class structure with deep inheritance trees and clever class switch-over mechanism was scrapped, replaced by a couple of classes with inheritance through composition. The smart scheduling was at the core of race conditions; replacing it with two trivial, rigid lists of jobs (realtime, and background) solved the issue.
And it's now some 6 years. The system works fine. Extra business logic algorithm had to be added once, it didn't take more work than it would before. Cosmetic changes of logic happen every couple of months, and need to be applied in three places instead of former one. The idea of business algorithm switch-over on the run appeared to run afoul of safety regulations, the on-the-fly change leading to transitions not allowed by law. The dataset switching, performed maybe once a year, requires extra two minutes of work versus what it was originally. Its structure was only ever expanded, which meant business logic also only was expanded occasionally.
Meanwhile, an area that lay fallow during the first version - interaction with external systems - underwent massive expansions. The fancy structure wouldn't help one bit with that. The range of systems that came up, what they did and what they needed was so wildly varied there's no way any preconceived structure to accept them would ever stand a chance. The lack of such system appeared a blessing, because adding them was straightforward; wherever they had to slice right into heart of the business logic in a completely new way, there was no struggle to break through extra abstraction layers; a single if() operating on easily accessible superglobal replacing twenty new methods to access areas previously isolated from the rest.
The bottom line is that you can't foresee every way the system may be modified or expanded, and making the system extendable in a way you guessed would be common may very well appear both completely useless (the system will never be extended that way) and thoroughly detrimental to expansion in a way that is required. Keeping the system SIMPLE from moment one, and instead of trying to account for every possibility, only doing what it needs to do in the simplest way it can do, is a much better approach to making it easy to expand. And - surprisingly, maybe - makes debug easier too.
Parent of my original post: "The Ethical obligation of a company is to follow the laws of the land and act in the best interests of their shareholders"
The company then has no shareholders. What is its ethical obligation then?
It's often used for systems that are way too small to ever need the resulting complication. And when the system needs to be extended, it frequently appears what it needs to work with doesn't fit the current implementation in the least, and instead of writing a trivial interface, you are forced to massage the MVC engine/framework into fitting the new thing.
It's a decent system if you know majority of requirements a'priori, the system is big, and can only grow in well understood ways.
If the system is to grow a lot from a small root in ways you can't even roughly foresee, MVC feels like the smart way to make it flexible and easy to expand. Until you encounter requirements that are completely orthogonal to current design, say, deadline/realtime reply requirements, massive parallellization, making the system distributed, or porting to small embedded.
Adding an extra page with some report, or a summary, or shuffling a piece of UI into a different UI branch is nice and clean in MVC, and these are the typical expansion types you foresee. But if it's something like mentioned above, you're suddenly in for a long haul and a lot of heartbreak. Modifying stuff within a framework is nice. Modifying the framework engine - not quite so. And MVC frameworks tend to be heavyweight and very complex; in a lot of cases more complex than your application written on top of them. Suddenly you need to modify code written by total strangers, often either way smarter than you, or worse, quite opposite... and the simplicity of your neat application means nothing in face of complexity of the framework engine.
You write 10 small functions, each a small non-trivial piece of code. You write one small function that binds them together. Next person after you needs to hunt around 11 files in the code to determine how that works and why it doesn't work to specs, instead of having the whole "device" right in 2-3 screens. Never mind if that's 10 + 1. What if it's 1000+100+10+1?
Or you have 6 different places where given piece of data is used, and it's used in 6 different slightly different variants. So you create these 6 methods - say, getters that in absence of valid data either supply a default, or throw an exception, or request the data and block until provided, or bypass the cache, or provide the data if not manually overridden, override value otherwise... and you write a 7th function, and now you need to dig through all the variants, only to find none of them suits your needs and you need to write a seventh one. And it's about impossible the next person will need your specific variant, but still - you moved the adaptation of input out of logic, and put it next to output of data storage. Would be a laudable endeavor... if it wasn't so counter-productive!
So, if I'm a legal shareholder of Apple NZ, and year by year it produces a $0 profit, is it acting in my interest?
Apple NZ is a sockpuppet entity with sole purpose of its existence being shielding the parent company from taxes. Its main purpose is NOT generating profit. This is an abuse of the system where successful local entities pay taxes, but unsuccessful ones don't have to - creation of a fake shell that artificially inflates local costs to a point of zero revenue to redirect actual income to a tax paradise.
The law normally doesn't allow such sock-puppets. If person X is shareholder of both the sock-puppet and parent company, using the sockpuppet to dodge the tax, they are about universally considered a tax fraud, and persecuted. But building a sufficiently complex hidden network of money flow and ownership, it's possible to obscure the fact how person X factually owns the sock-puppet, while not being legally the owner - it's still exactly the same tax fraud, but much harder to prove.
I'd like to see how Outlaw Apple Stores operate. Zero law protection and enforcement.
Of course as a law-abiding tax-paying citizen, you still enjoy protection of law. If you want to shoot the Apple store clerk, you're free to do so and he's not even allowed to shoot back.
I remember that from the TV/radio news; "A SCUD missile has been shot down in [area] by Patriot missiles. Parts of the missile fell onto the [city/district/area], injuring[or killing] [n] civilians." I remember this news happened at least three times at different occasions during the Gulf War. I specifically remember that because by the third time I completely facepalmed - by then not a single SCUD ever hit its target by any other means than "shot down by Patriot onto the target."
The difference is, that if you spot a decoy and identify it, leaving it alone is the best course of action. If you're unsure, not hitting it won't be much of a problem.
If you spot the drone carrying a small package underneath, you'd better be sure it's not flying over $3.5mln worth of infrastructure...
And yeah, the package could be styrofoam, but can you afford that risk?
Nah. Patriots shot down a bunch of SCUDs. Onto populated areas.
Considering SCUD accuracy was about 50km circle, in a country with lots of empty desert around cities, the Patriots enormously aided the SCUD guidance system in hitting the target.
Slashdot Mirror
Care to recommend a GOOD FM for systemd?
I mean, not list of all options and files in alphabetical orders with brief explanations what each does to another obscure file without giving any clue WHY and WHAT FOR, and why should I care. I want a guide, starting with overview of the logic, structure and purpose of main components, what are the purposes and tasks of systemd, how it achieves them, and how to control and modify them, in that order.
Currently, I found only two types of systemd docs: "inventory/catalogue of options", something an already proficient systemd developer could use as reference to recall finer details of given functions, and "voodoo programming" guides. Want A: Type X, press Y, enter Z. Something for a total newbie, to get given thing done and remain none the wiser. I'm yet to find something that allows one to "enter the world of systemd", and start understanding it.
Well, we don't happen to have money to hire a database designer, to invent the SQL queries that would do what 20 lines of Perl over JSON file can do.
Actually, we do use the relational database, except for the most wildly varying entries, there's a text field, which contains the JSON objects. I mean, if the field "measurement" may be an int, a float, an enum, an array, an array of arrays of variable length, containing int, float, NULL or NaN, or a structure composed of a string and three booleans, yeah, that can be normalized into a bunch of tables, and queries for these can be written, but... seriously, why?
"If I write this program in an easily extensible way, expanding this later will be a breeze."
Lots of classes, rich inheritance trees, broad project on top of a robust framework, making adding extra modules fairly easy. Your program is clean, well-documented, and has a logical structure, all according to best practices. It's also about 4 times bigger than it would really need to be, it takes 3 times as much RAM (primarily due to loading all the neat frameworks and libraries that you used "not to reinvent the wheel" even if you only use one or two simple functions from these), but who cares, this is the modern paradigm, and everything is automated and works so smoothly you can be nothing but proud of it. Now just to support it, fix some bugs, and implement extra features.
Then the new requirements arrive, you look at the email, you look at the top level schematics of your system and you realize, with a sinking feeling, that you never imagined the system would need to be expanded *that* way. And that this particular framework doesn't support this approach, and never will, because its authors decided they never plan to support it, or that the target platform doesn't support, and can't ever support the kind of libraries you use, or that you currently depend on a piece of hardware to do a job which you will need to write from scratch, or the new legal requirements (which are not disputable; new law says so) go completely against your system philosophy, which provides equivalent but completely different functionality, or the essential library just has been discontinued, and new security holes have been found in it...
Or at the very least, you realize that a feature that amounts to ten lines of code performing a really simple tricks requires you to create ten different files, two thousand lines of code, config and extras, and modification of several existing files, because the way the extensions of this type are applicable is writing a plugin which is a separate project with a whole non-trivial instantiation of framework, build system, security, and compatibility with your smart dynamic plugin loading mechanism. What would amount to pasting a 12-line function called once per tick from the main loop, amounts to a three-week project building the plugin/wrapper for that 10-line snippet.
You CAN NOT foresee future requirements. You CAN NOT plan all possible future extensions ahead of time. And the more you plan for, the more "flexible" you try to be, the larger and more rigid your project becomes in areas you failed to foresee, and the harder it will be to adapt it for these.
Yes, leave hooks for stuff you have it on a good authority WILL happen. Do not try to plan for every eventuality though. Write good clean code that does what it's meant to do, and doesn't try to be ready for anything else. It will be *easier* to expand once the time comes.
Ubuntu has a very solid backend/engine, but the frontend has been dumbed down to the level of a Fisher Prize toy.
It's a decent way to get started with Linux from zero, and a good thing for people who are computer-illiterate, but if one day you get tired with Ubuntu behaving like an overprotective mother of a 3-year-old (with you being the 3-year-old), just sudo apt install kubuntu-desktop to get a reasonable frontend replacement.
Are you sure?
Firefox/FreeBSD anyone? Or not sending UA string at all? Or Lynx/MS-DOS UA string?
TFA claims it was just a failsafe/fallback for "Other/Unsupported". I'm honestly curious.
"Ordnung ist Ordnung" ceased to be a valid devence since Nuremberg.
Professional doesn't take an unethical job.
It seems it's not active throttling, just fallback to failsafe set of features; it's not the issue of specifically "Firefox+Linux", it's the general "Other".
Instead of feature detection, they sniff the UA string and upon failing to find a "supported browser" serve code for "unsupported" which is woefully unoptimal.
So, not evil, just lazy and incompetent.
Edge/12.10136 (Linux)
Norwegian are efficient like hell in building tunnels.
When motorways were built in Poland, a factoid made rounds: 1km of motorway in Poland costs as much as 1km of tunnel through sheer rock in Norway.
I wonder what about the self-incrimination rule if the text of the password itself is incriminating.
Imagine I'm being charged with possession of child porn, but my password is "TheCorpseIsBuriedBehindTheGarage".
Revealing it would be direct self-incrimination, regardless of the drive content, wouldn't it?
Oh, the IDE can only go so far. It helps, but once you have the relevant logic spread over 20 or more files, no IDE will let you grasp it all.
I tried following what "smarter people" created before me. Preparing for every possible eventual expansion of the system - adding new business logic algorithms, new types of input data, new variants of output, dynamic switch of dataset and algorithm mid-execution, massive parallelism, with a lot of cross-thread communication and clever automatic scheduling of tasks. They had been mucking around with it for 3 years, making a system that was very elegant - and completely useless.
It appeared the underlying system requires everything to be single thread, running under RTOS, because critical operations were not being completed on time and race conditions resulting from the underlying system design abound. And the deadline was in half a year.
All that fancy work had to be scrapped and written from scratch, in a much simplified form only sparsely utilizing scraps of old logic. The whole fancy broad class structure with deep inheritance trees and clever class switch-over mechanism was scrapped, replaced by a couple of classes with inheritance through composition. The smart scheduling was at the core of race conditions; replacing it with two trivial, rigid lists of jobs (realtime, and background) solved the issue.
And it's now some 6 years. The system works fine. Extra business logic algorithm had to be added once, it didn't take more work than it would before. Cosmetic changes of logic happen every couple of months, and need to be applied in three places instead of former one. The idea of business algorithm switch-over on the run appeared to run afoul of safety regulations, the on-the-fly change leading to transitions not allowed by law. The dataset switching, performed maybe once a year, requires extra two minutes of work versus what it was originally. Its structure was only ever expanded, which meant business logic also only was expanded occasionally.
Meanwhile, an area that lay fallow during the first version - interaction with external systems - underwent massive expansions. The fancy structure wouldn't help one bit with that. The range of systems that came up, what they did and what they needed was so wildly varied there's no way any preconceived structure to accept them would ever stand a chance. The lack of such system appeared a blessing, because adding them was straightforward; wherever they had to slice right into heart of the business logic in a completely new way, there was no struggle to break through extra abstraction layers; a single if() operating on easily accessible superglobal replacing twenty new methods to access areas previously isolated from the rest.
The bottom line is that you can't foresee every way the system may be modified or expanded, and making the system extendable in a way you guessed would be common may very well appear both completely useless (the system will never be extended that way) and thoroughly detrimental to expansion in a way that is required. Keeping the system SIMPLE from moment one, and instead of trying to account for every possibility, only doing what it needs to do in the simplest way it can do, is a much better approach to making it easy to expand. And - surprisingly, maybe - makes debug easier too.
Parent of my original post: "The Ethical obligation of a company is to follow the laws of the land and act in the best interests of their shareholders"
The company then has no shareholders. What is its ethical obligation then?
Sufficiently complex hidden network of money flow and ownership.
The parent company doesn't pay taxes to NZ obviously.
Yes, that code is a bug.
Guess what real programmers do at least 60% of the time?
Fix bugs.
Any technique that obscures bugs is detrimental.
Whoa, so much hot air you could fly a blimp across the Pacific on it.
Professionalism isn't about staying at a job that doesn't pay your worth.
And with your attitude regarding requirements and salaries, you only qualify as a professional con artist.
But you've gotta admit make IS arcane if you want to use it for anything more complex than configure-build-install.
It's often used for systems that are way too small to ever need the resulting complication. And when the system needs to be extended, it frequently appears what it needs to work with doesn't fit the current implementation in the least, and instead of writing a trivial interface, you are forced to massage the MVC engine/framework into fitting the new thing.
It's a decent system if you know majority of requirements a'priori, the system is big, and can only grow in well understood ways.
If the system is to grow a lot from a small root in ways you can't even roughly foresee, MVC feels like the smart way to make it flexible and easy to expand. Until you encounter requirements that are completely orthogonal to current design, say, deadline/realtime reply requirements, massive parallellization, making the system distributed, or porting to small embedded.
Adding an extra page with some report, or a summary, or shuffling a piece of UI into a different UI branch is nice and clean in MVC, and these are the typical expansion types you foresee. But if it's something like mentioned above, you're suddenly in for a long haul and a lot of heartbreak. Modifying stuff within a framework is nice. Modifying the framework engine - not quite so. And MVC frameworks tend to be heavyweight and very complex; in a lot of cases more complex than your application written on top of them. Suddenly you need to modify code written by total strangers, often either way smarter than you, or worse, quite opposite... and the simplicity of your neat application means nothing in face of complexity of the framework engine.
You don't understand the difference between what a function claims to attempt to do versus what it actually achieves. You have no business in IT.
int returnRandomInt(int max)
{
return 4;
}
You write 10 small functions, each a small non-trivial piece of code. You write one small function that binds them together. Next person after you needs to hunt around 11 files in the code to determine how that works and why it doesn't work to specs, instead of having the whole "device" right in 2-3 screens. Never mind if that's 10 + 1. What if it's 1000+100+10+1?
Or you have 6 different places where given piece of data is used, and it's used in 6 different slightly different variants. So you create these 6 methods - say, getters that in absence of valid data either supply a default, or throw an exception, or request the data and block until provided, or bypass the cache, or provide the data if not manually overridden, override value otherwise... and you write a 7th function, and now you need to dig through all the variants, only to find none of them suits your needs and you need to write a seventh one. And it's about impossible the next person will need your specific variant, but still - you moved the adaptation of input out of logic, and put it next to output of data storage. Would be a laudable endeavor... if it wasn't so counter-productive!
So, if I'm a legal shareholder of Apple NZ, and year by year it produces a $0 profit, is it acting in my interest?
Apple NZ is a sockpuppet entity with sole purpose of its existence being shielding the parent company from taxes. Its main purpose is NOT generating profit. This is an abuse of the system where successful local entities pay taxes, but unsuccessful ones don't have to - creation of a fake shell that artificially inflates local costs to a point of zero revenue to redirect actual income to a tax paradise.
The law normally doesn't allow such sock-puppets. If person X is shareholder of both the sock-puppet and parent company, using the sockpuppet to dodge the tax, they are about universally considered a tax fraud, and persecuted. But building a sufficiently complex hidden network of money flow and ownership, it's possible to obscure the fact how person X factually owns the sock-puppet, while not being legally the owner - it's still exactly the same tax fraud, but much harder to prove.
I'd like to see how Outlaw Apple Stores operate. Zero law protection and enforcement.
Of course as a law-abiding tax-paying citizen, you still enjoy protection of law. If you want to shoot the Apple store clerk, you're free to do so and he's not even allowed to shoot back.
I remember that from the TV/radio news; "A SCUD missile has been shot down in [area] by Patriot missiles. Parts of the missile fell onto the [city/district/area], injuring[or killing] [n] civilians." I remember this news happened at least three times at different occasions during the Gulf War. I specifically remember that because by the third time I completely facepalmed - by then not a single SCUD ever hit its target by any other means than "shot down by Patriot onto the target."
I don't think the kid that owned that drone shares your optimism.
The difference is, that if you spot a decoy and identify it, leaving it alone is the best course of action. If you're unsure, not hitting it won't be much of a problem.
If you spot the drone carrying a small package underneath, you'd better be sure it's not flying over $3.5mln worth of infrastructure...
And yeah, the package could be styrofoam, but can you afford that risk?
Nah. Patriots shot down a bunch of SCUDs. Onto populated areas.
Considering SCUD accuracy was about 50km circle, in a country with lots of empty desert around cities, the Patriots enormously aided the SCUD guidance system in hitting the target.