This. I'm not especially prolific or talented, but even I generally tend to write code directly from the spec.
(GP)
Then you have examples - where someone shows you how to, e.g. draw a simple triangle using the documented opcodes and all of the boilerplate and set up necessary.
These are usually pretty useless, involve horrible paradigms only used by crazy people like a buinch of access macros for some sublanguage-of-the-week that the authors thought was chic, and don't yield any information beyond what the documentation says.
However, the GP's point about documentation like "opcode foo: does foo" stands. That said, if the documentation did tell me how efficient a given operation was, I'd take that into account, but I wouldn't necessarily treat it as gospel. A good amount of writing code is testing.
Considering packaging is exactly where a distro's development focus should be, I'd say they are working just fine. Also, APT isn't the packaging system, dpkg is.
That's why I predict that the Open Source protocol will be a bit player in a market dominated by an inferior protocol that does require internet access (it will be called "cloud access" soon enough), is completely insecure, and the developers of which are more interested in data harvesting than making it work better. Because sticker prices will be lower due to offsets from revenue from advertising/market intelligence, and consumers are stupid.
I pretty much gave up on Pandora after a couple years of subscription. Yeah, it finds some new artists, but it's obvious that the algorithm is biased towards predefined notions of genre, and there's no way to change the weights. They say they are constantly improving their algorithm, but I see/hear no real evidence of that. If they were, I'd expect more options to start appearing to allow advanced users to tweak stuff. Never saw any even as a paying user. I suspect these days it is more of a mechanical turk than an actual algorithm.
Given the comparative price/port of mini GE switches vs USB hubs, the cost argument just doesn't hold water. PoE can add some cost, but it's mounds better than USB power, so if the ethernet folks had made a crappy class1-only PoE standard early on, they probably could have played in the crap market. Point being, the USB folks could have, but didn't, use existing line coding standards and just cut corners on the protocol they ran over that coding. Hell they probably could have built a chip that was intended to be sold as an ethernet chip but fused to a USB chip on the rejected dies. Instead they hacked their own junk together likely out of hubris.
Ethernet does need to come up with a new standardized connector that caters to the thin device fanatics, however.
There are things that are completely ugly, and then there are things that are a matter of taste. Personally I like the look of solar panels and think they are a whole lot prettier than shingles.
However, these associations use the aesthetic excuse for banning people from putting any solar up even on back roofs. So we know where they are really coming from.
Also, please tell me how I peruse my old e-mail when my internet connection goes down or the provider has a service outage for a webmail app.
I have a hard enough time doing that in outook when the network is up and running smoothly.
Seriously, 10 minutes to search an inbox with just a few tens of thousands of emails in it? I pretty much have to keep both outlook and OWA open so I can use each to work around the serious deficiencies of the other.
I've generally found the people who make more than occasional use of calandering features are the most unproductive ones. I could entirely live without calandering myself.
To be fair, that's not what the topic of the whole thread is about. The GOP resistance to the solar indistry goes deeper than government subsidies. It goes way down into the trenches with local regulators and neighborhood associations doing the dirty work trying to bury would-be installers under mounds of bureaucratic paperwork and restrictions (not that I'm a big fan of deregulation, but some of the crap that is being pulled is clearly not for saftey purposes.)
it had a significantly lower value than my current car, which limited the maximum that insurance would ever have to pay for repairs
The premium should be dominated by the cost of the damage the car might do to other cars, property, and people, not the cost of the car itself, unless you opt in to the gold-plated buy-me-a-trip-to-the-bahamas-if-my-fender-gets-scratched add-ons.
Risk Pools have a purpose. A pool of one is not a pool.
I think you nailed it succinctly there. While it's a popular idea that responsible customer A should not have to pay for irresponsible customer B, and certainly it is good to encourage less risky behavior, insurance is supposed to work as a protection against risk. The finer the analysis done to create these micro-pools, the more likely it is that instead of being insured for a risk, you get blamed for it instead, even in cases where it really isn't your fault.
Example: you're driving on the highway and encounter a dangerous situation for which the safest solution is to speed up way past the speed limit -- e.g. you are beside a the first of a tandem trailer, the truck driver doesn't see you, and he starts to change into your lane. So you do, and you may get on "Flo"'s shit list for it, or not, depending on how some coder tuned some Kalman filter or whatnot.
Attempts have been made in the past to automate programming, it's never worked very well (or at all in some cases)
The places where it does work, you don't notice. Compilers/optimizers/JIT engines are automated programming. You tell the system what you want to do and behind the scenes it figures out all the stuff you did not tell it. Like not to actually check if X again if you have checked that earlier and X could not have changed, even if you told it to check X again because it was easier for you to write it that way.
That said, we have words for this in Perl5/Perl6, DWIM (Do What I Mean) and WAT (acronym open to conjecture and often followed by ?!?!) and the Perl6 folks are working under the hypothesis that every DWIM you add will cause and equal and opposing WAT, so to be careful not to DWIM just for the sake of it.
TFA sounds like an uber-DWIMmy initiative. The corresponding WAT behavior is almost guaranteed to be hilarious.
No, I don't trust applications to handle the security of packet data coming in.
In fact you do, unless you're running a pretty top notch L7 DPI box. And even then,,,
Besides, these days everything that's an app must be considered good and trustworthy. How else can we expect you to turn over all your data to criminals, much less corporations?
Making everyone adopt a new TCP stack is probably not going to happen.
Neither is it likely to happen that a true multipath helper will be built into core routers (e.g. something that uses TTL counters to determine when to take the second/third/etc preferred route in their route table and leaves the job of computing preferable paths to the end systems.) Which means what really needs to happen... won't. We've reached a technological glaciation point where the existing install base is dictating the direction of technology, rather than the other way around.
It's in-effect correct because there are lots of UDP protocols designed before the general concept of "do not amplify unauthenticated solicitations with a larger reply" finally sunk in. (Or at least, sunk in among more serious protocol designers/implementers.)
Because the ISPs can barely manage to tape the BGP infrastructure together in a stable fashion; there are numerous problems encountered when to ask a L3 router to perform at the speeds demanded at peering locations, and keeping a full trust mesh of ASNs and IP prefixes is beyond the state of the art (you have to not only know who's advertisements you can trust, but who's readvertisements of who's advertisements you can trust, etc, etc.) Both strict and loose reverse-path filtering are rarer to find in use the deeper towards the midddle of the network you go. Then there's IPv6's larger address space on top of that....
Just try clicking on the edit tab. Fix a simple spelling error to start. You don't even need an account, until you want to start building a reputation.
Or if you can't work up the nerve, go to the page discussion, edit the discussion, and comment there. The only important part there is to remember to write (~~~~) after your comment if you are not using an account.
The tendency to try to abstract activities that are essentially programs into a set of non-program-like objects has generally led to accumulation of byzantine cruft. This is especially true in the network packet processing and authentication domains. This isn't just a problem with GUIs. CLI utilities often want to just present the user with "objects" like rules and lists, and try to conceal flow control concepts by nesting contextually meaningful layers of these objects -- the meaning sof these layers often being ambiguously defined. Complex tasks crowbarred into that paradigm tend to explode geometrically into an unmanageable mess.
What's needed, across all domains, to enable those more GUI-oriented people to work with such concepts is a good GUI for program logic, and it needs to be built by very patient programmers listening intently to the needs of GUI-oriented users of average intelligence.
There might be spots where this is true, but in others it will improve performance, e.g. skipping unneeded operations that occur on all rules like incrmenting conters. Remember, iptables is actually somewhat of an abstraction itself.
I haven't been keeping up with how much intelligence vendors are putting in ethernet cards these days, but as far as I know, actually having firewall rules use on-card features has sadly lagged way behind what is offered. It would seem to me that, on the one hand, using a simple VM for the ruleset might theoretically make it easier for driver authors to try to analyse the rules and offload what can be offloaded to the card (probably doing the analysis in user-space and passing in a mix of nftables VM code and vendor-specific metal code.) That assumes the nftables code provides adequate hooks to do so.
On the other hand, the added flexibility could result in typical rulesets using new features that cannot be offloaded early in the ruleset, especially if user visibility about which rules have been offloaded to hardware is limited.
Not to mention, keeping a lot of said management facilities operational can very often waste as much time as they save. Another example is proprietary switch stack clustering protocols. They cost as much to manage their quirks and work around their defects as they save, unless you have a truly massive and abnormally homogeneous set of systems.
Slashdot Mirror
This. I'm not especially prolific or talented, but even I generally tend to write code directly from the spec.
(GP)
Then you have examples - where someone shows you how to, e.g. draw a simple triangle using the documented opcodes and all of the boilerplate and set up necessary.
These are usually pretty useless, involve horrible paradigms only used by crazy people like a buinch of access macros for some sublanguage-of-the-week that the authors thought was chic, and don't yield any information beyond what the documentation says.
However, the GP's point about documentation like "opcode foo: does foo" stands. That said, if the documentation did tell me how efficient a given operation was, I'd take that into account, but I wouldn't necessarily treat it as gospel. A good amount of writing code is testing.
You should have just made up your own words to fit the letters.
Considering packaging is exactly where a distro's development focus should be, I'd say they are working just fine. Also, APT isn't the packaging system, dpkg is.
That's why I predict that the Open Source protocol will be a bit player in a market dominated by an inferior protocol that does require internet access (it will be called "cloud access" soon enough), is completely insecure, and the developers of which are more interested in data harvesting than making it work better. Because sticker prices will be lower due to offsets from revenue from advertising/market intelligence, and consumers are stupid.
It seems to be the way of the world.
I pretty much gave up on Pandora after a couple years of subscription. Yeah, it finds some new artists, but it's obvious that the algorithm is biased towards predefined notions of genre, and there's no way to change the weights. They say they are constantly improving their algorithm, but I see/hear no real evidence of that. If they were, I'd expect more options to start appearing to allow advanced users to tweak stuff. Never saw any even as a paying user. I suspect these days it is more of a mechanical turk than an actual algorithm.
Given the comparative price/port of mini GE switches vs USB hubs, the cost argument just doesn't hold water. PoE can add some cost, but it's mounds better than USB power, so if the ethernet folks had made a crappy class1-only PoE standard early on, they probably could have played in the crap market. Point being, the USB folks could have, but didn't, use existing line coding standards and just cut corners on the protocol they ran over that coding. Hell they probably could have built a chip that was intended to be sold as an ethernet chip but fused to a USB chip on the rejected dies. Instead they hacked their own junk together likely out of hubris.
Ethernet does need to come up with a new standardized connector that caters to the thin device fanatics, however.
There are things that are completely ugly, and then there are things that are a matter of taste. Personally I like the look of solar panels and think they are a whole lot prettier than shingles.
However, these associations use the aesthetic excuse for banning people from putting any solar up even on back roofs. So we know where they are really coming from.
This is why users of solutions like Outlook are encouraged to use archiving.
Sooooo 80's. I want my mail client to save me work, not create busywork for me.
Also, please tell me how I peruse my old e-mail when my internet connection goes down or the provider has a service outage for a webmail app.
I have a hard enough time doing that in outook when the network is up and running smoothly.
Seriously, 10 minutes to search an inbox with just a few tens of thousands of emails in it? I pretty much have to keep both outlook and OWA open so I can use each to work around the serious deficiencies of the other.
I've generally found the people who make more than occasional use of calandering features are the most unproductive ones. I could entirely live without calandering myself.
To be fair, that's not what the topic of the whole thread is about. The GOP resistance to the solar indistry goes deeper than government subsidies. It goes way down into the trenches with local regulators and neighborhood associations doing the dirty work trying to bury would-be installers under mounds of bureaucratic paperwork and restrictions (not that I'm a big fan of deregulation, but some of the crap that is being pulled is clearly not for saftey purposes.)
it had a significantly lower value than my current car, which limited the maximum that insurance would ever have to pay for repairs
The premium should be dominated by the cost of the damage the car might do to other cars, property, and people, not the cost of the car itself, unless you opt in to the gold-plated buy-me-a-trip-to-the-bahamas-if-my-fender-gets-scratched add-ons.
Your post offered me the inventive to go some spell checker insurance.
Risk Pools have a purpose. A pool of one is not a pool.
I think you nailed it succinctly there. While it's a popular idea that responsible customer A should not have to pay for irresponsible customer B, and certainly it is good to encourage less risky behavior, insurance is supposed to work as a protection against risk. The finer the analysis done to create these micro-pools, the more likely it is that instead of being insured for a risk, you get blamed for it instead, even in cases where it really isn't your fault.
Example: you're driving on the highway and encounter a dangerous situation for which the safest solution is to speed up way past the speed limit -- e.g. you are beside a the first of a tandem trailer, the truck driver doesn't see you, and he starts to change into your lane. So you do, and you may get on "Flo"'s shit list for it, or not, depending on how some coder tuned some Kalman filter or whatnot.
Attempts have been made in the past to automate programming, it's never worked very well (or at all in some cases)
The places where it does work, you don't notice. Compilers/optimizers/JIT engines are automated programming. You tell the system what you want to do and behind the scenes it figures out all the stuff you did not tell it. Like not to actually check if X again if you have checked that earlier and X could not have changed, even if you told it to check X again because it was easier for you to write it that way.
That said, we have words for this in Perl5/Perl6, DWIM (Do What I Mean) and WAT (acronym open to conjecture and often followed by ?!?!) and the Perl6 folks are working under the hypothesis that every DWIM you add will cause and equal and opposing WAT, so to be careful not to DWIM just for the sake of it.
TFA sounds like an uber-DWIMmy initiative. The corresponding WAT behavior is almost guaranteed to be hilarious.
No, I don't trust applications to handle the security of packet data coming in.
In fact you do, unless you're running a pretty top notch L7 DPI box. And even then,,,
Besides, these days everything that's an app must be considered good and trustworthy. How else can we expect you to turn over all your data to criminals, much less corporations?
Making everyone adopt a new TCP stack is probably not going to happen.
Neither is it likely to happen that a true multipath helper will be built into core routers (e.g. something that uses TTL counters to determine when to take the second/third/etc preferred route in their route table and leaves the job of computing preferable paths to the end systems.) Which means what really needs to happen... won't. We've reached a technological glaciation point where the existing install base is dictating the direction of technology, rather than the other way around.
It's in-effect correct because there are lots of UDP protocols designed before the general concept of "do not amplify unauthenticated solicitations with a larger reply" finally sunk in. (Or at least, sunk in among more serious protocol designers/implementers.)
Because the ISPs can barely manage to tape the BGP infrastructure together in a stable fashion; there are numerous problems encountered when to ask a L3 router to perform at the speeds demanded at peering locations, and keeping a full trust mesh of ASNs and IP prefixes is beyond the state of the art (you have to not only know who's advertisements you can trust, but who's readvertisements of who's advertisements you can trust, etc, etc.) Both strict and loose reverse-path filtering are rarer to find in use the deeper towards the midddle of the network you go. Then there's IPv6's larger address space on top of that....
Actually meth labs also smell like cat urine. So it might be that all the tiny elves that live inside the device were "overclocked" so to speak.
It will be like HD and 3D. In a few years it will become standard on mid range and even cheap TVs.
...and People On The Internet(TM) will still be complaining that it's all "hype" and will never make it in the market, even though they own one.
Just try clicking on the edit tab. Fix a simple spelling error to start. You don't even need an account, until you want to start building a reputation.
Or if you can't work up the nerve, go to the page discussion, edit the discussion, and comment there. The only important part there is to remember to write (~~~~) after your comment if you are not using an account.
The tendency to try to abstract activities that are essentially programs into a set of non-program-like objects has generally led to accumulation of byzantine cruft. This is especially true in the network packet processing and authentication domains. This isn't just a problem with GUIs. CLI utilities often want to just present the user with "objects" like rules and lists, and try to conceal flow control concepts by nesting contextually meaningful layers of these objects -- the meaning sof these layers often being ambiguously defined. Complex tasks crowbarred into that paradigm tend to explode geometrically into an unmanageable mess.
What's needed, across all domains, to enable those more GUI-oriented people to work with such concepts is a good GUI for program logic, and it needs to be built by very patient programmers listening intently to the needs of GUI-oriented users of average intelligence.
There might be spots where this is true, but in others it will improve performance, e.g. skipping unneeded operations that occur on all rules like incrmenting conters. Remember, iptables is actually somewhat of an abstraction itself.
I haven't been keeping up with how much intelligence vendors are putting in ethernet cards these days, but as far as I know, actually having firewall rules use on-card features has sadly lagged way behind what is offered. It would seem to me that, on the one hand, using a simple VM for the ruleset might theoretically make it easier for driver authors to try to analyse the rules and offload what can be offloaded to the card (probably doing the analysis in user-space and passing in a mix of nftables VM code and vendor-specific metal code.) That assumes the nftables code provides adequate hooks to do so.
On the other hand, the added flexibility could result in typical rulesets using new features that cannot be offloaded early in the ruleset, especially if user visibility about which rules have been offloaded to hardware is limited.
Not to mention, keeping a lot of said management facilities operational can very often waste as much time as they save. Another example is proprietary switch stack clustering protocols. They cost as much to manage their quirks and work around their defects as they save, unless you have a truly massive and abnormally homogeneous set of systems.