The idea that it's a bad idea to roll your own security features because you're probably not a security expert is not something that is necessarily applicable to an organization as large as Apple, which can certainly afford to employ as many security researchers as it needs to to match the security knowledge of other common security tool organizations.
...but apparently cannot afford the engineers needed to write a thorough test suite for just about anything.
much easier to work with, more flexible and communicative, less arrogant.
Still they have a long way to go. Agree that other vendors have the same issues. However, with the amount of MS installed, working around their derps still occupies an inordinate amount of my time (25% of my last year was spent forklifting a system whose sole purpose is to clean up after Microsoft's mess), so they present the most obvious neck to strangle.
The thing I hate the most about their products they do not have a monopoly on: selling managers framework systems whose major purpose seems to be to coax the customer into a situation where buying more stuff is the easiest solution. Of course the systems do stuff there is already OpenSource to deal with, but of course they add that one little feature not available in open source that sounds real good in a sales pitch, while not being nearly as flexible underneath where it matters, because you just simply cannot be flexible if the people applying your product are working blind.
It's actually a drain on embedded systems to do so much through shell scripting, having all those processes running scripts in an interpreted language. Systemd supposedly will allow a leaner build.
and at the same time putting both their kids and every other kid in their area at serious risk.
Their kids, sure, there's a case to be made about that. However, I don't see the same amount of rage about parents who allow/encourage their kids to particpate over-competitive sports programs which result in a lot injuries due to the mass acceptance of the "no pain, no gain" mantra.
Also, they aren't putting other vaccinated kids in their area at much extra risk.
We are having to face this at work. In order to upgrade our WiFi network to 11ac we are going to have to double the number of APs and put many of them inside dormatory rooms. Despite current lack of evidence as to any health effects (notwithstanding placing the AP 2 feet from where your head is when you sleep, which is against official recommendations and we plan to make impossible,) housing will probably offer people an option as to whether they prefer one of the rooms that does not have them, or at least have to deal with complaints. I don't blame them if they do -- a college housing department isn't the right place to have a showdown over scientific research, and on the off chance that some hitherto unsurveyed adverse effect does become evident, liability issues could ensue.
As far as the anti-vax people go there were a small but significant number of parents who noticed autism start to develop very close to the time when their children got vaccinated. This could have been coincidence or it could have been due to the children having gene expressions that made them susceptible to some adverse reaction, and studies that look at the general population might not be able to tease out any statistical signifigance if there is a small subpopulation that is more susceptible. The thimerisol connection was apparently a mass-media-induced panic, but I can't blame the parents for wanting an explanation, and can't expect them to all be scientists nor really expect them to even have a bearing as to which scientific authorities are trustworthy, given the current influence of money on research. People love to hate on them for some reason, but I refuse to.
It's a specialized application, with a very specific purpose, that it does very well.
I don't buy that. Then, I've opened the hood of the jackd source enough to see that it was fully capable of doing the job, without sacrificing anything. Once you have a low latency sound server, providing a buffering module for more casual use is not that challenging. Once you have a patch panel capable of routing sound around as well as jackd, providing for pluggable device support is a natural extension of that.
Your argument is the equivalent of saying that web browsers are highly specialized HTML/HTTP renderers and extending them to handle scripting would compromise their ability to fetch HTML over HTTP and render it.
All of the above list read more like a "things Poettering could have fixed in jackd instead of throwing an entirely new wrench into the gears" than a justification for PA, personally. Jackd's plugin architecture could easily have provided for a service discovery plugin, naive app plugin, etc.
Pretty sure you can already do volume control of individual apps in jackd, though,
That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it
You don't count jackd as competition?
Instead PA works in perfect unison with Jack,
Last time I worked with getting the two to interoperate, pulse's jack module was calling long-deprecated libjack functionality.
That said, these days the only problem I really have with pulse is its long dependency list (less than awesome level of package modularity), given that the state of jackd has deteriorated so. If I was into pro audio, I'd probably have more problems with both packages.
This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.
That's disenheartneing to hear, considering how many times I have had to hack the hell out of my init scripts to kill avahi because I DO NOT WANT IT, and the fact that pulseaudio came in and made a mess where jackd was just starting to make things sane, and the time spent would have been better spent improving jackd.
But on the other hand, jackd had that unfortunate attempt to fork into a C++ reimplementation, and lost its (never fully supported) ability to run as a systemwide daemon so background daemons could use the soundcard, and pulseaudio has since turned an about face and started supporting a systemwide daemon, more RT features (AFAIK not quite yet up to snuff with what JACKd offered) and has been less of a general nuisance recently.
So, there's something to be said for software that starts out as inferior but due to the charisma and/or persistance of its proponents, eventually manages to get a larger development community, because that community will beat it into shape, and hopefully manage to shed as much cruft left over from the inferior design through a concerted deprecation effort. It's a hassle to us users, but works out eventually. It looks like this has happened and will continue to happen with systemd.
We could avoid that if the competent projects were somehow given an injection of participants, but people that write necessarily-complex code generally tend to spend most of their time doing just that, not glad-handing on mailing lists, whereas the authors of insufficient simplied solutions have more time to politic. The only part about that that stings is that the latter often uses the former as a cheat-sheet going forward and does not bother to give credit,
I have to agree with PP in that perfect security is possible. Proveably so. You can try to hedge around this fact with sophomoric arguments that show that it is possible to use a perfectly secure system in an insecure manner. That it an excercise in semantics since exhibiting the insecurity requires abusing the system. In order to define security you have to define what it is you are attempting to be secure against. A door with a deadbolt on the inside, when locked, is perfectly secure against lockpick attacks for example. Trying to use it to defend against people with chainsaws and blowtorches, however, is abusing that particular security system.
However the PP seems to think security is directly proportional to the simplicity of a system. It is also possible in more complex systems, and in fact, there are simple insecure systems that can be made perfectly secure by making them more complex. Witness strnlen.
Putting all the intelligence in the hosts allows for more resiliency, since it takes a lot to the bring the whole infrastructure down this way.
It's the way to go. Any intellegence added to the core should merely be simple tweaks to enable more intelligence at the edges. For example, one might plausibly argue that making core routers select second/third most-preferred destination routes for a packet based on a TTL % on IP packets would allow end-systems to experimentally find the fastest performing route through the internet by trying different values on their TTLs/option fields. One could not reasonably argue for expecting core devices to maintain per-connection or even per-client/netblock state in an attempt to find alternate routes for each client connection.
Software defined networks are definitely a way to bring some intelligence back in the infrastructure of IP networks. We'll see if it will enable a smarter Internet or not.
From what I've seen of SDN it's a bunch of people who think they can abstract network services in a simple model, but who have no compreshension of the intrinsic differences in the heterogeneous mixture of devices employed, so they haven't even scratched the surface of being able to build a taxonomy/capabilities-enumeration for things like, for example, how many CAM entries are available for edge switch filters on a given switch model. Without that information, SDN applications have no way of doing any serious budgeting before launching a request into the network gear, and since the device might happily take the commands and provision a halfway-functional service that is dropping 5% of packets, rather than reject the request, and SDN has no real provisions for testing services before putting them in production, SDN is doomed to be confined to data centers where equipment has been carefully kept homogeneous.
Most people using SDN that I;'ve seen are doing so for enterprise (including server farm) LAN, not core internet.
Don't make wide generilised sweeping statements as they are most often wrong. For example, properly implemented SAV would be complexity, yet also a strength.
Diagrams have a few small advantages over language when it comes to reactive programming, which is dominant in basic digital circuits. As noted by others, EEs today use text at least as much as diagram, because silicon has caught up to implementing some of the concepts best expressed by words.
What will eventually become popular IMO is a mild graphical enhancement to text based languages, e.g. using arrows/traces for complicated parallel flow control while the program keeps the same general text-file form for OO, modularity, and expressions. Past that point, there won't be much benefit to further conversion to graphical representations.
Basically graphical elements amount to adding gesticulation to language -- there are benefits, but compared to the total power of the system, they are but a small fraction.
(Words also have one advantage in that they can utilize both/either auditory and visual channels, and so offer a disability-resistant method of communication.)
Why write three quick and dirty sentence-fragments on how to do it, when you can record a 10 minute video and post it to YouTube?
This. And it's getting even worse -- even enterprise grade vendors are starting to do it to document their products while allowing their more formal manuals to languish.
Anyone who wonders why we still use language instead of pictures really needs to spend some time trying to find information in a manual for a GUI-based application versus finding it for the CLI (or writing the two styles of manual, for that matter.) Yes, learnig to read well and type well takes a lot of practice. It is also worth every second.
Each language has its nuances. In Java, if you write bad code, you get slowness and RAM hogging and so many classes that most people decide to use the developer documentation to heat their homes rather than work woth it. In, say, Perl if you write bad code you get line noise and unreadable source. I've seen some Java client-side applications that run perfectly fast (minus the initial VM startup), and not because they were doing something simple. Heck one even gave me a glimpse of the good-ol-days when you didn't have to refresh the screen manually to get evrything that should have updated to actually update and keys made characters appear WHEN you typed them not half a second later. This despite all the drawbacks of running on a VM that is far divorced from the hardware (doesn't even have uints.)
One can speculate on what makes some development outfits competent and others not. Certainly, having an automated test system that flags performance penalties as regressions couldn't hurt.
The two solutions (algorithmically ensconced or via companion fake data) are basically equivalent, because everything that is not part of the true cleartext is part of the algorithm. This is an implementation detail.
Slashdot Mirror
Should be easy enough to figure out from a properly maintained public repo log. Just how opensource is the apple SSL kit?
Their solution was to change to an API that they knew could be consistent.
Of course. Rolling your own SSL stack is so much more efficient a use of engineers time than backporting patches.
The idea that it's a bad idea to roll your own security features because you're probably not a security expert is not something that is necessarily applicable to an organization as large as Apple, which can certainly afford to employ as many security researchers as it needs to to match the security knowledge of other common security tool organizations.
...but apparently cannot afford the engineers needed to write a thorough test suite for just about anything.
If the language would require the braces it would even be better...
You mean like this?
if (0)
{ goto fail; }
{ goto fail; }
exit(0);
much easier to work with, more flexible and communicative, less arrogant.
Still they have a long way to go. Agree that other vendors have the same issues. However, with the amount of MS installed, working around their derps still occupies an inordinate amount of my time (25% of my last year was spent forklifting a system whose sole purpose is to clean up after Microsoft's mess), so they present the most obvious neck to strangle.
The thing I hate the most about their products they do not have a monopoly on: selling managers framework systems whose major purpose seems to be to coax the customer into a situation where buying more stuff is the easiest solution. Of course the systems do stuff there is already OpenSource to deal with, but of course they add that one little feature not available in open source that sounds real good in a sales pitch, while not being nearly as flexible underneath where it matters, because you just simply cannot be flexible if the people applying your product are working blind.
It's actually a drain on embedded systems to do so much through shell scripting, having all those processes running scripts in an interpreted language. Systemd supposedly will allow a leaner build.
and at the same time putting both their kids and every other kid in their area at serious risk.
Their kids, sure, there's a case to be made about that. However, I don't see the same amount of rage about parents who allow/encourage their kids to particpate over-competitive sports programs which result in a lot injuries due to the mass acceptance of the "no pain, no gain" mantra.
Also, they aren't putting other vaccinated kids in their area at much extra risk.
We are having to face this at work. In order to upgrade our WiFi network to 11ac we are going to have to double the number of APs and put many of them inside dormatory rooms. Despite current lack of evidence as to any health effects (notwithstanding placing the AP 2 feet from where your head is when you sleep, which is against official recommendations and we plan to make impossible,) housing will probably offer people an option as to whether they prefer one of the rooms that does not have them, or at least have to deal with complaints. I don't blame them if they do -- a college housing department isn't the right place to have a showdown over scientific research, and on the off chance that some hitherto unsurveyed adverse effect does become evident, liability issues could ensue.
As far as the anti-vax people go there were a small but significant number of parents who noticed autism start to develop very close to the time when their children got vaccinated. This could have been coincidence or it could have been due to the children having gene expressions that made them susceptible to some adverse reaction, and studies that look at the general population might not be able to tease out any statistical signifigance if there is a small subpopulation that is more susceptible. The thimerisol connection was apparently a mass-media-induced panic, but I can't blame the parents for wanting an explanation, and can't expect them to all be scientists nor really expect them to even have a bearing as to which scientific authorities are trustworthy, given the current influence of money on research. People love to hate on them for some reason, but I refuse to.
People might start to demand more statistically valid electoral recounts.
It's a specialized application, with a very specific purpose, that it does very well.
I don't buy that. Then, I've opened the hood of the jackd source enough to see that it was fully capable of doing the job, without sacrificing anything. Once you have a low latency sound server, providing a buffering module for more casual use is not that challenging. Once you have a patch panel capable of routing sound around as well as jackd, providing for pluggable device support is a natural extension of that.
Your argument is the equivalent of saying that web browsers are highly specialized HTML/HTTP renderers and extending them to handle scripting would compromise their ability to fetch HTML over HTTP and render it.
All of the above list read more like a "things Poettering could have fixed in jackd instead of throwing an entirely new wrench into the gears" than a justification for PA, personally. Jackd's plugin architecture could easily have provided for a service discovery plugin, naive app plugin, etc.
Pretty sure you can already do volume control of individual apps in jackd, though,
That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it
You don't count jackd as competition?
Instead PA works in perfect unison with Jack,
Last time I worked with getting the two to interoperate, pulse's jack module was calling long-deprecated libjack functionality.
That said, these days the only problem I really have with pulse is its long dependency list (less than awesome level of package modularity), given that the state of jackd has deteriorated so. If I was into pro audio, I'd probably have more problems with both packages.
This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.
That's disenheartneing to hear, considering how many times I have had to hack the hell out of my init scripts to kill avahi because I DO NOT WANT IT, and the fact that pulseaudio came in and made a mess where jackd was just starting to make things sane, and the time spent would have been better spent improving jackd.
But on the other hand, jackd had that unfortunate attempt to fork into a C++ reimplementation, and lost its (never fully supported) ability to run as a systemwide daemon so background daemons could use the soundcard, and pulseaudio has since turned an about face and started supporting a systemwide daemon, more RT features (AFAIK not quite yet up to snuff with what JACKd offered) and has been less of a general nuisance recently.
So, there's something to be said for software that starts out as inferior but due to the charisma and/or persistance of its proponents, eventually manages to get a larger development community, because that community will beat it into shape, and hopefully manage to shed as much cruft left over from the inferior design through a concerted deprecation effort. It's a hassle to us users, but works out eventually. It looks like this has happened and will continue to happen with systemd.
We could avoid that if the competent projects were somehow given an injection of participants, but people that write necessarily-complex code generally tend to spend most of their time doing just that, not glad-handing on mailing lists, whereas the authors of insufficient simplied solutions have more time to politic. The only part about that that stings is that the latter often uses the former as a cheat-sheet going forward and does not bother to give credit,
I have to agree with PP in that perfect security is possible. Proveably so. You can try to hedge around this fact with sophomoric arguments that show that it is possible to use a perfectly secure system in an insecure manner. That it an excercise in semantics since exhibiting the insecurity requires abusing the system. In order to define security you have to define what it is you are attempting to be secure against. A door with a deadbolt on the inside, when locked, is perfectly secure against lockpick attacks for example. Trying to use it to defend against people with chainsaws and blowtorches, however, is abusing that particular security system.
However the PP seems to think security is directly proportional to the simplicity of a system. It is also possible in more complex systems, and in fact, there are simple insecure systems that can be made perfectly secure by making them more complex. Witness strnlen.
Putting all the intelligence in the hosts allows for more resiliency, since it takes a lot to the bring the whole infrastructure down this way.
It's the way to go. Any intellegence added to the core should merely be simple tweaks to enable more intelligence at the edges. For example, one might plausibly argue that making core routers select second/third most-preferred destination routes for a packet based on a TTL % on IP packets would allow end-systems to experimentally find the fastest performing route through the internet by trying different values on their TTLs/option fields. One could not reasonably argue for expecting core devices to maintain per-connection or even per-client/netblock state in an attempt to find alternate routes for each client connection.
Software defined networks are definitely a way to bring some intelligence back in the infrastructure of IP networks. We'll see if it will enable a smarter Internet or not.
From what I've seen of SDN it's a bunch of people who think they can abstract network services in a simple model, but who have no compreshension of the intrinsic differences in the heterogeneous mixture of devices employed, so they haven't even scratched the surface of being able to build a taxonomy/capabilities-enumeration for things like, for example, how many CAM entries are available for edge switch filters on a given switch model. Without that information, SDN applications have no way of doing any serious budgeting before launching a request into the network gear, and since the device might happily take the commands and provision a halfway-functional service that is dropping 5% of packets, rather than reject the request, and SDN has no real provisions for testing services before putting them in production, SDN is doomed to be confined to data centers where equipment has been carefully kept homogeneous.
Most people using SDN that I;'ve seen are doing so for enterprise (including server farm) LAN, not core internet.
Don't make wide generilised sweeping statements as they are most often wrong. For example, properly implemented SAV would be complexity, yet also a strength.
Diagrams have a few small advantages over language when it comes to reactive programming, which is dominant in basic digital circuits. As noted by others, EEs today use text at least as much as diagram, because silicon has caught up to implementing some of the concepts best expressed by words.
What will eventually become popular IMO is a mild graphical enhancement to text based languages, e.g. using arrows/traces for complicated parallel flow control while the program keeps the same general text-file form for OO, modularity, and expressions. Past that point, there won't be much benefit to further conversion to graphical representations.
Basically graphical elements amount to adding gesticulation to language -- there are benefits, but compared to the total power of the system, they are but a small fraction.
(Words also have one advantage in that they can utilize both/either auditory and visual channels, and so offer a disability-resistant method of communication.)
Why write three quick and dirty sentence-fragments on how to do it, when you can record a 10 minute video and post it to YouTube?
This. And it's getting even worse -- even enterprise grade vendors are starting to do it to document their products while allowing their more formal manuals to languish.
Anyone who wonders why we still use language instead of pictures really needs to spend some time trying to find information in a manual for a GUI-based application versus finding it for the CLI (or writing the two styles of manual, for that matter.) Yes, learnig to read well and type well takes a lot of practice. It is also worth every second.
Umm... bridges? Power lines?
Eh, it will give us something else to prop up against telephone poles alongside the lost hubcaps.
Given that, it is completely mandatory that Web2.0+ completely ignore this attribute and never use it.
Each language has its nuances. In Java, if you write bad code, you get slowness and RAM hogging and so many classes that most people decide to use the developer documentation to heat their homes rather than work woth it. In, say, Perl if you write bad code you get line noise and unreadable source. I've seen some Java client-side applications that run perfectly fast (minus the initial VM startup), and not because they were doing something simple. Heck one even gave me a glimpse of the good-ol-days when you didn't have to refresh the screen manually to get evrything that should have updated to actually update and keys made characters appear WHEN you typed them not half a second later. This despite all the drawbacks of running on a VM that is far divorced from the hardware (doesn't even have uints.)
One can speculate on what makes some development outfits competent and others not. Certainly, having an automated test system that flags performance penalties as regressions couldn't hurt.
Does the animal urine go to waste, or is it used by, for example, having livestock graze in fallow fields?
Probably yes mostly and yes. But... how would one go about collecting it? I don't think catheders would pass muster with the SPCAs.
The two solutions (algorithmically ensconced or via companion fake data) are basically equivalent, because everything that is not part of the true cleartext is part of the algorithm. This is an implementation detail.