Simplicity is out there; you just have to find it. Obviously, if you're writing a general-purpose operating system that has to use a minimum of resources, be nearly impervious from malicious attackers hitting it from all directions, scale to the largest workloads, and run on hardware ranging from smart watches to multi-petaflop supercomputers, it's not going to be simple. That's just the reality of it. Designing such a thing is no simple task. One size definitely does not fit all.
Relative simplicity in coding can still be found in line of business applications, workplace automation, that kind of thing. Basically, if you're writing a specific program that will only ever be used by your team of staff in a 10-person office, it's perfectly fine to hard-code a file path into your program code, or require a very specific version of Ruby or Java, or write a brittle 300-line function that could really use some refactoring to be more maintainable later. If you double-click it and it does its thing and exits, you're done -- no need to write unit tests, or roll it up into a redistributable.war or.ear, or test it on IRIX and Solaris to make sure the build system builds on anything, or transport yourself 5 years in the future and make sure it'll still run perfectly on Windows 10. There's just no need. If it breaks, you can fix it in an afternoon and no one will even notice it was broken.
It sounds like TFA author just wants an easy programming job in a back office or IT skunkworks somewhere. Which is fine -- we need people to do that, or the world wouldn't work. Not every piece of executable code ever written was intended, or should be intended, to work perfectly fine on an 81-bit microprocessor in a kerosene-powered cheese grater running System/360, and to support a user doing something totally out of the design scope with the code.
Are you writing general-purpose software that is for sale or freely available to be used in a vast number of diverse scenarios? If so, you need to somehow manage the complexity in order to support all those scenarios.
If you're not writing general-purpose software, you can strip out many of the layers of software engineering that you're taught in college these days, because much of it is designed to manage that complexity. If the complexity isn't there, and to the point doesn't NEED to be there, then the layers of bureaucracy and red tape and process are pointless and can be scrapped.
That's not to say it should be a total ad-hoc hackjob. You should still use version control, no matter what, for anything beyond a 1-line batch file that you could recreate from memory. But if your version control consists of a git repo sitting on your local hard drive, and you don't have any code review before you push, who cares? You're still a developer doing productive work.
Not everyone is Linus Torvalds. Not everyone has to write code that will stand the test of time and operate correctly in totally unforeseen contexts. It's needlessly expensive to make it so. IT skunkworks exists for a very good reason.
It's simple: Just install a program on your developers' computers that tracks how often (how many times in general, and for how long) the developer switches focus away from their IDE. If they're constantly googling, looking up reference docs or algorithms, etc., chances are they are doing something that's new, untested, uncharted territory for them. If they're just rattling off hundreds of SLOC at a time, while only needing IntelliSense as an aide, chances are most of it will work on the first attempt.
Programmers who use books made of real, physical paper foil this test and should be summarily fired.
Completely agree. FiOS is 1/8th mile away from my house but they won't bring it the last couple hundred feet. I'd be stuck on ADSL, but I am using 100+ GB/month on my unlimited data, symmetrical 30 Mbps LTE, tethering my 5 GHz 802.11ac smartphone (Galaxy S5) to my 5 GHz 802.11ac wifi adapter on my computer. I uploaded an hour-long HD video to youtube yesterday in about an hour. If Verizon Wireless doesn't want me tying up ~40% of the bandwidth on the local tower, they're more than welcome to ask their non-Wireless brethren to run a fiber cable down the street; I'd be the first to sign up.
Oh yeah, and in 2007, the Verizon rep who CAME TO OUR DOOR (and repeatedly left fliers on the door handle, and called, and so forth) said that we were "weeks" away from getting FiOS (that is an exact quote -- "weeks"). By my estimation, we're somewhere in the 350-week range from the time when they promised us FiOS, and still no sign of it. Usually when someone says "weeks", a reasonable person would think less than 10. An unreasonable person would think no more than 100. But 350? Yeah. FiOS simply isn't coming here, ever. They've stopped deploying and pocketed the money they received from local and state government to roll it out. I wish I could find a reason to sue them, but I'm pretty happy tightening the screws on them by exploiting my unlimited LTE data plan to the max, which I'm sure hurts them a lot when they multiply my data usage by $10/GB to see how much money they would be making if I were on a limited plan.
I really dislike Verizon and Verizon Wireless, but I really have no choice right now. And when it comes down to it, symmetrical 30 meg with 60 ms pings isn't that bad on an unlimited data plan. My phone's CPU tends to get a little hotter than its battery would like, which always results in my phones having a significantly degraded battery early on their lifespan, but them's the breaks.
A lot of people who do this kind of thing on a volunteer basis, are either already making a decent living wage writing software and do this in their spare time; or, they are hoping that their contributions will attract attention from corporations that can then hire them to work on the software (thus funding the development of FOSS and also furthering the company's goals by improving the software they use).
I don't think SysVinit is particularly good at anything, especially considering it's SysV's complete lack of functionality that caused the emergence of 9 different ways to do network config (Debian way, RHEL way, Gentoo way, and many others); 9 different ways to do logging (syslog, rsyslog, syslog-ng, etc.); and so on with starting daemons, yada yada.
That said, I'm really somewhat disappointed that, as powerful of a unifying force within the Linux distro world Poettering's contributions have been, they completely neglect non-Linux FOSS operating systems. I've been a RHEL/Debian hand for years and years, but recently I've started falling in love with SmartOS, which is based on Illumos/OpenIndiana/OpenSolaris. It actually has a REALLY good built-in init system called SMF, which, like all init systems, sucks at some things but is really really nifty at others. One thing I can say for certain about SMF is it kicks SysVinit's ass from one side of the world to the other. It's always disappointing when a project team for something other than systemd, which previously compiled fine on SmartOS, decides to add a hard dependency on Systemd. It basically guarantees that your project will be forked for all the people out there who aren't using Systemd.
Looks like Xorg doesn't strictly require systemd, which is the CORRECT way to integrate Systemd into a project: make it an OPTIONAL dependency. I have absolutely no qualms with a project ADDING support for Systemd while maintaining support for non-Systemd systems, such as non-Linux OSes. I have a problem when something I need on SmartOS is basically hard-locked to the Linux kernel by indirection to hard-depending on Systemd.
As eloquently said by Truxton Spangler (portrayed by Michael Cristofer) at the end of the show Rubicon (which was pulled off the air after 1 season, IMHO, because it hit too close to home for the oligarchs):
"Do you think anyone will give a shit?"
That's the problem. It's the boiling frog problem. Most people will downplay this move as Microsoft exiting the mobile business. But it's much more than that. It's just one more step down the ladder into tyranny.
I think there's a difference between "being willing to accept the risk of my credit card(s) being compromised on the internet" and "being willing to accept the risk of every account password I have being compromised on the internet". I essentially have insurance to help me recover losses from my credit cards. Having every bank account and retirement account drained by an enterprising criminal with access to all of my account and personal details is on a completely different risk level.
Let's assume for the moment that you're correct and that there is a difference in risk level between submitting your name, address, email, credit card number, CVV2 (these are the fields required for a standard online order form), and storing all your passwords on the Internet.
Let's assume someone actually does intercept your order form, and gets all the above-mentioned personal data on you (perhaps because the company processing your order stored all your order info in an unprotected SQL database). Many people acknowledge that, with this amount of personal information, a lot of damage can be done, starting with identity theft. Yes, there are many protections on credit cards, but other personal details can be used as leverage to get access to even more details. This is starting to look like more than simple credit card theft.
Also, if you're not storing your passwords on some website, where ARE you storing them? If you don't store any passwords anywhere, chances are you don't have a perfect, long-term eidetic memory, so you probably use the same password everywhere. That's just as risky, if not riskier, than using LastPass -- if an attacker compromises just one of the sites you use, they can try that password on random sites across the web and gain access to a slew of your accounts.
Let's be a bit more charitable and assume you use completely different passwords on different sites. OK, now we're getting serious. You are going to need somewhere to store all these passwords -- that's the simple reality of it. Only the extremely rare individual can remember them all in their head. So what do you use? A paper card file? That's great, unless you invite a guest in your house who may not prove 100% trustworthy, like an A/C repairman... Or if you happen to live in a dangerous part of the world where house robberies are common, a password card file would definitely be something a thief would want to steal. Or you could just get really unlucky, even in a low-crime area, and get robbed anyway. The same logic as the card file effectively applies to such things as KeePassX, since an unhindered thief can take your laptop, phone, or whatever you use to store your KeePass database on. Once they have your device, you're basically owned. Remember, we have to be fair here; you're assuming the thief is smart enough to break the security model of a business that builds its entire reputation around security, like LastPass, so we have to also assume the thief is smart enough to break the security model on your physical box, whatever it may be. Most people are not going to employ physical or digital countermeasures that are sufficient to keep very sophisticated thieves from breaking into your box once they have physical access. Full disk encryption is still quite the rare thing, and brute forcing a typical-length KeePass password isn't all that hard anymore with GPGPU or an EC2 compute cluster once you've obtained the database file.
Now, since LastPass supports two-factor authentication via various physical methods, such as the YubiKey, simply obtaining your LastPass password will not be sufficient for them to gain access. They'll also have to be a sophisticated thief, which brings us back to square one, where LastPass and KeePass are about equal on security: you'd have to get robbed, and the thief would have to steal the correct things, then break into them in order to gain access. I concede that users of LastPass or similar services who opt out of two-factor authentication are taking a greater risk,
I have a YubiKey NEO that works perfectly with LastPass, both on desktop systems via USB, and on my mobile device via NFC. The key has internal non-volatile storage but no battery; when it's plugged in and used, it atomically reads from storage; uses the input from storage as a salt to generate a unique one-time password (a long ASCII string); transmits the password to the host device; then updates the non-volatile storage with some magic to ensure that the next one-time password is unique, unguessable and cryptographically secure.
An attacker would need my LastPass password (which is not, itself, stored in my LastPass vault); my physical YubiKey; and the knowledge to use both in tandem, in order to gain access to my LastPass account.
To claim that it is impossible or futile to store passwords on the web is missing the point. The nature of the content is immaterial. If you are of the opinion that passwords can't be securely stored on the web, then you must also believe that NO content can securely be stored on the web -- in which case, have fun living in the dark ages, where the only thing you can do with the web is share information that you're fine with being released to the general public.
I, on the other hand, really like it when I can click a few buttons and a package with something I need shows up on my doorstep a day or two later. But oh, if it's "futile" to secure anything on the web, you couldn't give a company your address or financials to bill you for shipment! Better call them up on the telephone to place your order, because nobody has ever wiretapped a telephone, right?
No. The fix here is to identify the security vulnerabilities and fix them, not to spread FUD about security on the web.
As Moore's Law starts to hit a brick wall (a better analogy would be: stretching a strong rubber band; and it takes more and more force the more you stretch it), the amount of processing power you can cram onto a single IC die starts to hit an upper bound. The bounds that prevail upon it are primarily related to heat dissipation and power, both of which are available only up to a certain amount before they become impractical for the average (or even enthusiast) PC budget.
To put this another way: up until about Intel's Ivy Bridge generation, we could reliably expect very major CPU performance increases every 1-2 years. Now, the only way to see major CPU performance increases is to buy higher-TDP chips (like the -E variants, which have 6 cores and/or higher clocks and more cache, but are larger, more expensive die that produce more heat). If you asked Intel to print exactly the same size of silicon using exactly the same TDP with the three most recent architectures they've come up with, and you benchmarked these three CPUs with air-cooling, you would see only minimal improvement.
Where am I going with this? Well, sound takes a non-trivial amount of CPU to process. Complex sound, with many separate channels, positional audio effects, reverb, etc. takes even more CPU to process. So, to put it simply: if game developers want to continue to demand more CPU headroom to run their game/simulation (as AI algorithms get more advanced, more objects to keep track of, etc., CPU demands out of games are trending upwards), they aren't going to get that headroom from users who purchase "mainstream" processors. And the enthusiast processors are so expensive that only a small fraction of the market can afford them, which means it's impractical to set your system requirements for your game such that you can't play it smoothly without such a processor.
Where they CAN get that headroom, though, is by freeing up CPU resources by offloading sound processing onto a dedicated IC. By physically separating the sound processing from the CPU die, it's very similar to having a coprocessor (analogous to the GPU), allowing for much more complex sound-generation or sound-processing algorithms, without asking users to buy a $1000 CPU. And the best part is that a quite good sound card, like the SoundBlaster Z, with considerable offloading capability, can be purchased for under $100. That's well within any gamer's budget.
I don't know if I believe all the crock about the fidelity and the SNR and the "audible difference" between the DAC on a SoundBlaster and the DAC on a decent motherboard chipset. But I definitely believe that, if you want to have extremely high sound quality in your game, with dynamically generated effects in reaction to game events, this is going to chew up a lot of cycles from SOME processor. You get to choose whether those cycles come out of your CPU, or your sound card. Personally, I can't afford an i7-4960X, so I'll take the sound card any day of the week.
Try installing a tablet or laptop running your favorite (customizable) OS on a movable arm or swivel that's mounted to the dashboard. Mounted electronics that don't interfere with your field of view are legal in many jurisdictions.
If their idea of "Automotive-grade" software is anything like Honda's concept of it, the infotainment system will randomly crash; exhibit severe bugs; lack obvious options like removing a paired bluetooth phone without resetting the whole damn thing to its factory defaults; and break several standards along the way for minimal to no compatibility with anything but a few "blessed" bluetooth devices.
No idea if Honda's HandsFree Link uses Linux at its core, but the untested dreck auto manufacturers have been putting out for the past few years makes me wonder if they're hiring Charlie the dealership manager's son ("he's a whiz kid with computers!!") to code up these programs.
The one exception appears to be Tesla, though I've never been inside of one.
I'm glad the IRS is looking into 501(3)(c) organizations that really have no standing to be classified as such. While they're at it, why don't they force the B&M Gates Foundation to stop pretending to be a "charity" and reveal it as the for-profit tax haven that it is? Sure, they throw a lot of money at short-term problems that might help people in the short term, but it seems their primary mission is to establish a dependency on western pharmaceuticals by developing nations. If that's not for-profit, I don't know what is. Capitalists are lining up at the gates (no pun intended) to help push along this tax haven and further its reach. It's disgusting, really.
I've had this since release day of Windows 8.0. Microsoft seems to be following almost exactly in the footsteps of Stardock with their products Start8 and ModernMix. Let's see: they brought back the start button (Start8 does that); they made a "close" bar with an X on Metro apps so they act more like desktop apps (ModernMix does that and then some, since it can make Metro apps windowed and resizeable); they are going to bring back the start menu in Windows 9 (Start8 has done that since its release around the Windows 8 preview)... So I've basically been running Windows 9 since release day of Windows 8.0. The one thing that confounds me is why Stardock didn't patent these things first so they could sue Microsoft for a trillion dollars for blatantly stealing all of their ideas (admittedly, many of these ideas involve "stealing" from previous versions of Windows, but the Metro UI enhancements in ModernMix are new to Metro.)
Having to look at a 500+ PPI 5.5" screen on an RDP session, or some other application or website where the designer assumes the same DPI as their standard 96 DPI 17" monitor at work, is going to MAKE me go blind.
Then I'll literally be throwing money blindly at the next smartphone. Obviously, my preferred choice will be able to accomplish everything I ever want to do with the smartphone by starting with "OK Google..."
Cue conspiracy theories about Google wanting to make the general population blind.
The problem with their experimental approach is that they did not attempt to break the warp barrier by using a hollowed-out nuclear missile as the basis for a ship. Because we can totally break the warp barrier with a manned spaceflight *before* we can do it with tiny particles, right?
Just a while back, kernel.org got some infrastructure upgrades, including two HP MSA70s. Hopefully this invisible user account doesn't affect their boxen, seeing how they're a different (but similar) model number.
Right -- an *open* beta, *weeks* before launch. Any other software than an MMO would be just about ready to go when the number of days till production can be counted on your fingers and toes.
The actual game client isn't all that bad. The real failure is their server infrastructure, which appears unable to handle the demand of the players.
Also, there are hundreds of instances of each area, yet some instances are so busy that it can take an hour just to gain access to it. They've apparently never heard of load balancing or ahead-of-time slot reservation, which leaves users in a potentially infinite loop like this:
1) Log into the game and wait a very long time to "Retrieve the list of characters". 2) Click the "Play" button on your character and wait a very long time for the game to load. 3) Get into your previous instance, which is only rarely a problem. 4) Click through all the mission dialogs that say you've completed the mission, because you have, and you're trying to leave, and it won't let you. 5) Try to warp out of the instance and into the "sector space". 6) Curse at the system when it announces that the map is full. Gee, if it was full, why couldn't you have told me that *before* all the long load times?
The instances seem to have a fairly small number of slots (about 40), and they are picked either at random or based on the least busy instance at any given time. But if a particular region is particularly popular (and sector space is very, VERY popular), the only available instances will have, say, 38/40 or 39/40 slots in use. So by the time you load, some other person has already taken all the slots, and you get kicked all the way back to the login screen. Chance to pick another instance? Forget it. All the way back to step 1.
It's this kind of simple-minded instance management that makes the game so bad, and improving it would require a major refactoring of the existing network protocol, impacting both the client and the server in a major way.
If this were a problem back in closed beta, it would make sense that such an ad-hoc system were in place -- after all, there's still months till release, and ample time to refactor this kind of stuff. But at this point they're practically printing the manuals and burning the CDs for the box sets, and from here on out it's just minor fixes to keep the thing running.
Or at least, that's how everything except MMOs work. But from past experience with MMOs, the *real* technical state of this game is actually closer to late-alpha than retail.
I pre-ordered like most people, but it appears that Cryptic didn't plan to handle the load on their servers. My biggest gripe with the game right now is that the service itself is extremely unreliable -- half the time I can't get in, and when I can get in, I get disconnected after 5 - 10 minutes of play.
Kind of a self-fulfilling prophecy that, with this kind of service (or lack thereof), people will get angry and stop playing. And then they'll have *plenty* of available capacity on their servers. Plenty.
The problem in this thread seems to be "I want to install ANY audio-using application and have it Just Work (tm)". This is a more pragmatic wish that has nothing to do with the theoretical arguments about the One True API that have been raging for years.
From my perspective, there is no One True API. As long as multiple audio APIs exist, applications that use them will too. This is a fact of life. To accommodate this, we have several choices:
1. Parts of the sound stack can natively support legacy APIs, allowing us to seamlessly move from the old to new. Example: PulseAudio supports ESD API. 2. Parts of the sound stack can forward audio from one layer to another, be it from the "old" to the "new" or vice versa. Example: ALSA forwards to PulseAudio using libasound_module_pcm_pulse; PulseAudio forwards to JACK using module-jack-{sink,source}. 3. A direct route is neither here nor there, but a multi-hop route is still feasible (example: OSS Proxy -> PulseAudio -> ALSA).
I just want to add that I am neither pro-PulseAudio nor anti-PulseAudio. There are applications that use the PulseAudio API particularly well -- for instance, Gstreamer and Skype 2.1 Beta. For these apps, PulseAudio works very well, so I see no reason to exclude PulseAudio from my sound stack. As long as it is useful, I will include it as part of my sound stack. _Part Of_. The other parts are designed to take care of audio APIs and use cases that PulseAudio alone cannot handle. Unless Lennart wants to implement every last audio API under the sun natively in Pulseaudio as a module, just as he did with ESD, then I don't think I will ever arrive at a situation where PulseAudio -> ALSA is the full extent of my sound stack -- especially not while popular apps out there still use APIs of JACK, OSS, etc.
Max, I also like to play around with stuff, and I feel your pain that Foo Application has a relatively poor chance of using the APIs that your sound stack supports. But, there are actually very many ways to allow applications to use different audio APIs at the same time, in parallel, by chaining together multiple APIs or sound servers. This is worst solution in terms of performance, but the best solution in terms of compatibility. With the right configuration, 99% of sound-using apps will "just work", regardless of what API they use.
Slashdot Mirror
Simplicity is out there; you just have to find it. Obviously, if you're writing a general-purpose operating system that has to use a minimum of resources, be nearly impervious from malicious attackers hitting it from all directions, scale to the largest workloads, and run on hardware ranging from smart watches to multi-petaflop supercomputers, it's not going to be simple. That's just the reality of it. Designing such a thing is no simple task. One size definitely does not fit all.
Relative simplicity in coding can still be found in line of business applications, workplace automation, that kind of thing. Basically, if you're writing a specific program that will only ever be used by your team of staff in a 10-person office, it's perfectly fine to hard-code a file path into your program code, or require a very specific version of Ruby or Java, or write a brittle 300-line function that could really use some refactoring to be more maintainable later. If you double-click it and it does its thing and exits, you're done -- no need to write unit tests, or roll it up into a redistributable .war or .ear, or test it on IRIX and Solaris to make sure the build system builds on anything, or transport yourself 5 years in the future and make sure it'll still run perfectly on Windows 10. There's just no need. If it breaks, you can fix it in an afternoon and no one will even notice it was broken.
It sounds like TFA author just wants an easy programming job in a back office or IT skunkworks somewhere. Which is fine -- we need people to do that, or the world wouldn't work. Not every piece of executable code ever written was intended, or should be intended, to work perfectly fine on an 81-bit microprocessor in a kerosene-powered cheese grater running System/360, and to support a user doing something totally out of the design scope with the code.
Are you writing general-purpose software that is for sale or freely available to be used in a vast number of diverse scenarios? If so, you need to somehow manage the complexity in order to support all those scenarios.
If you're not writing general-purpose software, you can strip out many of the layers of software engineering that you're taught in college these days, because much of it is designed to manage that complexity. If the complexity isn't there, and to the point doesn't NEED to be there, then the layers of bureaucracy and red tape and process are pointless and can be scrapped.
That's not to say it should be a total ad-hoc hackjob. You should still use version control, no matter what, for anything beyond a 1-line batch file that you could recreate from memory. But if your version control consists of a git repo sitting on your local hard drive, and you don't have any code review before you push, who cares? You're still a developer doing productive work.
Not everyone is Linus Torvalds. Not everyone has to write code that will stand the test of time and operate correctly in totally unforeseen contexts. It's needlessly expensive to make it so. IT skunkworks exists for a very good reason.
It's simple: Just install a program on your developers' computers that tracks how often (how many times in general, and for how long) the developer switches focus away from their IDE. If they're constantly googling, looking up reference docs or algorithms, etc., chances are they are doing something that's new, untested, uncharted territory for them. If they're just rattling off hundreds of SLOC at a time, while only needing IntelliSense as an aide, chances are most of it will work on the first attempt.
Programmers who use books made of real, physical paper foil this test and should be summarily fired.
LTE has native IPv6. So in that respect, us Verizon Wireless customers are ahead of the game.
Completely agree. FiOS is 1/8th mile away from my house but they won't bring it the last couple hundred feet. I'd be stuck on ADSL, but I am using 100+ GB/month on my unlimited data, symmetrical 30 Mbps LTE, tethering my 5 GHz 802.11ac smartphone (Galaxy S5) to my 5 GHz 802.11ac wifi adapter on my computer. I uploaded an hour-long HD video to youtube yesterday in about an hour. If Verizon Wireless doesn't want me tying up ~40% of the bandwidth on the local tower, they're more than welcome to ask their non-Wireless brethren to run a fiber cable down the street; I'd be the first to sign up.
Oh yeah, and in 2007, the Verizon rep who CAME TO OUR DOOR (and repeatedly left fliers on the door handle, and called, and so forth) said that we were "weeks" away from getting FiOS (that is an exact quote -- "weeks"). By my estimation, we're somewhere in the 350-week range from the time when they promised us FiOS, and still no sign of it. Usually when someone says "weeks", a reasonable person would think less than 10. An unreasonable person would think no more than 100. But 350? Yeah. FiOS simply isn't coming here, ever. They've stopped deploying and pocketed the money they received from local and state government to roll it out. I wish I could find a reason to sue them, but I'm pretty happy tightening the screws on them by exploiting my unlimited LTE data plan to the max, which I'm sure hurts them a lot when they multiply my data usage by $10/GB to see how much money they would be making if I were on a limited plan.
I really dislike Verizon and Verizon Wireless, but I really have no choice right now. And when it comes down to it, symmetrical 30 meg with 60 ms pings isn't that bad on an unlimited data plan. My phone's CPU tends to get a little hotter than its battery would like, which always results in my phones having a significantly degraded battery early on their lifespan, but them's the breaks.
A lot of people who do this kind of thing on a volunteer basis, are either already making a decent living wage writing software and do this in their spare time; or, they are hoping that their contributions will attract attention from corporations that can then hire them to work on the software (thus funding the development of FOSS and also furthering the company's goals by improving the software they use).
I don't think SysVinit is particularly good at anything, especially considering it's SysV's complete lack of functionality that caused the emergence of 9 different ways to do network config (Debian way, RHEL way, Gentoo way, and many others); 9 different ways to do logging (syslog, rsyslog, syslog-ng, etc.); and so on with starting daemons, yada yada.
That said, I'm really somewhat disappointed that, as powerful of a unifying force within the Linux distro world Poettering's contributions have been, they completely neglect non-Linux FOSS operating systems. I've been a RHEL/Debian hand for years and years, but recently I've started falling in love with SmartOS, which is based on Illumos/OpenIndiana/OpenSolaris. It actually has a REALLY good built-in init system called SMF, which, like all init systems, sucks at some things but is really really nifty at others. One thing I can say for certain about SMF is it kicks SysVinit's ass from one side of the world to the other. It's always disappointing when a project team for something other than systemd, which previously compiled fine on SmartOS, decides to add a hard dependency on Systemd. It basically guarantees that your project will be forked for all the people out there who aren't using Systemd.
Looks like Xorg doesn't strictly require systemd, which is the CORRECT way to integrate Systemd into a project: make it an OPTIONAL dependency. I have absolutely no qualms with a project ADDING support for Systemd while maintaining support for non-Systemd systems, such as non-Linux OSes. I have a problem when something I need on SmartOS is basically hard-locked to the Linux kernel by indirection to hard-depending on Systemd.
As eloquently said by Truxton Spangler (portrayed by Michael Cristofer) at the end of the show Rubicon (which was pulled off the air after 1 season, IMHO, because it hit too close to home for the oligarchs):
"Do you think anyone will give a shit?"
That's the problem. It's the boiling frog problem. Most people will downplay this move as Microsoft exiting the mobile business. But it's much more than that. It's just one more step down the ladder into tyranny.
I think there's a difference between "being willing to accept the risk of my credit card(s) being compromised on the internet" and "being willing to accept the risk of every account password I have being compromised on the internet". I essentially have insurance to help me recover losses from my credit cards. Having every bank account and retirement account drained by an enterprising criminal with access to all of my account and personal details is on a completely different risk level.
Let's assume for the moment that you're correct and that there is a difference in risk level between submitting your name, address, email, credit card number, CVV2 (these are the fields required for a standard online order form), and storing all your passwords on the Internet.
Let's assume someone actually does intercept your order form, and gets all the above-mentioned personal data on you (perhaps because the company processing your order stored all your order info in an unprotected SQL database). Many people acknowledge that, with this amount of personal information, a lot of damage can be done, starting with identity theft. Yes, there are many protections on credit cards, but other personal details can be used as leverage to get access to even more details. This is starting to look like more than simple credit card theft.
Also, if you're not storing your passwords on some website, where ARE you storing them? If you don't store any passwords anywhere, chances are you don't have a perfect, long-term eidetic memory, so you probably use the same password everywhere. That's just as risky, if not riskier, than using LastPass -- if an attacker compromises just one of the sites you use, they can try that password on random sites across the web and gain access to a slew of your accounts.
Let's be a bit more charitable and assume you use completely different passwords on different sites. OK, now we're getting serious. You are going to need somewhere to store all these passwords -- that's the simple reality of it. Only the extremely rare individual can remember them all in their head. So what do you use? A paper card file? That's great, unless you invite a guest in your house who may not prove 100% trustworthy, like an A/C repairman... Or if you happen to live in a dangerous part of the world where house robberies are common, a password card file would definitely be something a thief would want to steal. Or you could just get really unlucky, even in a low-crime area, and get robbed anyway. The same logic as the card file effectively applies to such things as KeePassX, since an unhindered thief can take your laptop, phone, or whatever you use to store your KeePass database on. Once they have your device, you're basically owned. Remember, we have to be fair here; you're assuming the thief is smart enough to break the security model of a business that builds its entire reputation around security, like LastPass, so we have to also assume the thief is smart enough to break the security model on your physical box, whatever it may be. Most people are not going to employ physical or digital countermeasures that are sufficient to keep very sophisticated thieves from breaking into your box once they have physical access. Full disk encryption is still quite the rare thing, and brute forcing a typical-length KeePass password isn't all that hard anymore with GPGPU or an EC2 compute cluster once you've obtained the database file.
Now, since LastPass supports two-factor authentication via various physical methods, such as the YubiKey, simply obtaining your LastPass password will not be sufficient for them to gain access. They'll also have to be a sophisticated thief, which brings us back to square one, where LastPass and KeePass are about equal on security: you'd have to get robbed, and the thief would have to steal the correct things, then break into them in order to gain access. I concede that users of LastPass or similar services who opt out of two-factor authentication are taking a greater risk,
I have a YubiKey NEO that works perfectly with LastPass, both on desktop systems via USB, and on my mobile device via NFC. The key has internal non-volatile storage but no battery; when it's plugged in and used, it atomically reads from storage; uses the input from storage as a salt to generate a unique one-time password (a long ASCII string); transmits the password to the host device; then updates the non-volatile storage with some magic to ensure that the next one-time password is unique, unguessable and cryptographically secure.
An attacker would need my LastPass password (which is not, itself, stored in my LastPass vault); my physical YubiKey; and the knowledge to use both in tandem, in order to gain access to my LastPass account.
To claim that it is impossible or futile to store passwords on the web is missing the point. The nature of the content is immaterial. If you are of the opinion that passwords can't be securely stored on the web, then you must also believe that NO content can securely be stored on the web -- in which case, have fun living in the dark ages, where the only thing you can do with the web is share information that you're fine with being released to the general public.
I, on the other hand, really like it when I can click a few buttons and a package with something I need shows up on my doorstep a day or two later. But oh, if it's "futile" to secure anything on the web, you couldn't give a company your address or financials to bill you for shipment! Better call them up on the telephone to place your order, because nobody has ever wiretapped a telephone, right?
No. The fix here is to identify the security vulnerabilities and fix them, not to spread FUD about security on the web.
As Moore's Law starts to hit a brick wall (a better analogy would be: stretching a strong rubber band; and it takes more and more force the more you stretch it), the amount of processing power you can cram onto a single IC die starts to hit an upper bound. The bounds that prevail upon it are primarily related to heat dissipation and power, both of which are available only up to a certain amount before they become impractical for the average (or even enthusiast) PC budget.
To put this another way: up until about Intel's Ivy Bridge generation, we could reliably expect very major CPU performance increases every 1-2 years. Now, the only way to see major CPU performance increases is to buy higher-TDP chips (like the -E variants, which have 6 cores and/or higher clocks and more cache, but are larger, more expensive die that produce more heat). If you asked Intel to print exactly the same size of silicon using exactly the same TDP with the three most recent architectures they've come up with, and you benchmarked these three CPUs with air-cooling, you would see only minimal improvement.
Where am I going with this? Well, sound takes a non-trivial amount of CPU to process. Complex sound, with many separate channels, positional audio effects, reverb, etc. takes even more CPU to process. So, to put it simply: if game developers want to continue to demand more CPU headroom to run their game/simulation (as AI algorithms get more advanced, more objects to keep track of, etc., CPU demands out of games are trending upwards), they aren't going to get that headroom from users who purchase "mainstream" processors. And the enthusiast processors are so expensive that only a small fraction of the market can afford them, which means it's impractical to set your system requirements for your game such that you can't play it smoothly without such a processor.
Where they CAN get that headroom, though, is by freeing up CPU resources by offloading sound processing onto a dedicated IC. By physically separating the sound processing from the CPU die, it's very similar to having a coprocessor (analogous to the GPU), allowing for much more complex sound-generation or sound-processing algorithms, without asking users to buy a $1000 CPU. And the best part is that a quite good sound card, like the SoundBlaster Z, with considerable offloading capability, can be purchased for under $100. That's well within any gamer's budget.
I don't know if I believe all the crock about the fidelity and the SNR and the "audible difference" between the DAC on a SoundBlaster and the DAC on a decent motherboard chipset. But I definitely believe that, if you want to have extremely high sound quality in your game, with dynamically generated effects in reaction to game events, this is going to chew up a lot of cycles from SOME processor. You get to choose whether those cycles come out of your CPU, or your sound card. Personally, I can't afford an i7-4960X, so I'll take the sound card any day of the week.
Try installing a tablet or laptop running your favorite (customizable) OS on a movable arm or swivel that's mounted to the dashboard. Mounted electronics that don't interfere with your field of view are legal in many jurisdictions.
If their idea of "Automotive-grade" software is anything like Honda's concept of it, the infotainment system will randomly crash; exhibit severe bugs; lack obvious options like removing a paired bluetooth phone without resetting the whole damn thing to its factory defaults; and break several standards along the way for minimal to no compatibility with anything but a few "blessed" bluetooth devices. No idea if Honda's HandsFree Link uses Linux at its core, but the untested dreck auto manufacturers have been putting out for the past few years makes me wonder if they're hiring Charlie the dealership manager's son ("he's a whiz kid with computers!!") to code up these programs. The one exception appears to be Tesla, though I've never been inside of one.
I'm glad the IRS is looking into 501(3)(c) organizations that really have no standing to be classified as such. While they're at it, why don't they force the B&M Gates Foundation to stop pretending to be a "charity" and reveal it as the for-profit tax haven that it is? Sure, they throw a lot of money at short-term problems that might help people in the short term, but it seems their primary mission is to establish a dependency on western pharmaceuticals by developing nations. If that's not for-profit, I don't know what is. Capitalists are lining up at the gates (no pun intended) to help push along this tax haven and further its reach. It's disgusting, really.
I've had this since release day of Windows 8.0. Microsoft seems to be following almost exactly in the footsteps of Stardock with their products Start8 and ModernMix. Let's see: they brought back the start button (Start8 does that); they made a "close" bar with an X on Metro apps so they act more like desktop apps (ModernMix does that and then some, since it can make Metro apps windowed and resizeable); they are going to bring back the start menu in Windows 9 (Start8 has done that since its release around the Windows 8 preview)... So I've basically been running Windows 9 since release day of Windows 8.0. The one thing that confounds me is why Stardock didn't patent these things first so they could sue Microsoft for a trillion dollars for blatantly stealing all of their ideas (admittedly, many of these ideas involve "stealing" from previous versions of Windows, but the Metro UI enhancements in ModernMix are new to Metro.)
Having to look at a 500+ PPI 5.5" screen on an RDP session, or some other application or website where the designer assumes the same DPI as their standard 96 DPI 17" monitor at work, is going to MAKE me go blind. Then I'll literally be throwing money blindly at the next smartphone. Obviously, my preferred choice will be able to accomplish everything I ever want to do with the smartphone by starting with "OK Google..." Cue conspiracy theories about Google wanting to make the general population blind.
The problem with their experimental approach is that they did not attempt to break the warp barrier by using a hollowed-out nuclear missile as the basis for a ship. Because we can totally break the warp barrier with a manned spaceflight *before* we can do it with tiny particles, right?
Just a while back, kernel.org got some infrastructure upgrades, including two HP MSA70s. Hopefully this invisible user account doesn't affect their boxen, seeing how they're a different (but similar) model number.
Michael Cote, an analyst at RedMon
:)
No wonder he isn't blown out of the water by the open source world -- he's a RedMond drone
Right -- an *open* beta, *weeks* before launch. Any other software than an MMO would be just about ready to go when the number of days till production can be counted on your fingers and toes.
The actual game client isn't all that bad. The real failure is their server infrastructure, which appears unable to handle the demand of the players.
Also, there are hundreds of instances of each area, yet some instances are so busy that it can take an hour just to gain access to it. They've apparently never heard of load balancing or ahead-of-time slot reservation, which leaves users in a potentially infinite loop like this:
1) Log into the game and wait a very long time to "Retrieve the list of characters".
2) Click the "Play" button on your character and wait a very long time for the game to load.
3) Get into your previous instance, which is only rarely a problem.
4) Click through all the mission dialogs that say you've completed the mission, because you have, and you're trying to leave, and it won't let you.
5) Try to warp out of the instance and into the "sector space".
6) Curse at the system when it announces that the map is full. Gee, if it was full, why couldn't you have told me that *before* all the long load times?
The instances seem to have a fairly small number of slots (about 40), and they are picked either at random or based on the least busy instance at any given time. But if a particular region is particularly popular (and sector space is very, VERY popular), the only available instances will have, say, 38/40 or 39/40 slots in use. So by the time you load, some other person has already taken all the slots, and you get kicked all the way back to the login screen. Chance to pick another instance? Forget it. All the way back to step 1.
It's this kind of simple-minded instance management that makes the game so bad, and improving it would require a major refactoring of the existing network protocol, impacting both the client and the server in a major way.
If this were a problem back in closed beta, it would make sense that such an ad-hoc system were in place -- after all, there's still months till release, and ample time to refactor this kind of stuff. But at this point they're practically printing the manuals and burning the CDs for the box sets, and from here on out it's just minor fixes to keep the thing running.
Or at least, that's how everything except MMOs work. But from past experience with MMOs, the *real* technical state of this game is actually closer to late-alpha than retail.
I pre-ordered like most people, but it appears that Cryptic didn't plan to handle the load on their servers. My biggest gripe with the game right now is that the service itself is extremely unreliable -- half the time I can't get in, and when I can get in, I get disconnected after 5 - 10 minutes of play.
Kind of a self-fulfilling prophecy that, with this kind of service (or lack thereof), people will get angry and stop playing. And then they'll have *plenty* of available capacity on their servers. Plenty.
The problem in this thread seems to be "I want to install ANY audio-using application and have it Just Work (tm)". This is a more pragmatic wish that has nothing to do with the theoretical arguments about the One True API that have been raging for years.
From my perspective, there is no One True API. As long as multiple audio APIs exist, applications that use them will too. This is a fact of life. To accommodate this, we have several choices:
1. Parts of the sound stack can natively support legacy APIs, allowing us to seamlessly move from the old to new. Example: PulseAudio supports ESD API.
2. Parts of the sound stack can forward audio from one layer to another, be it from the "old" to the "new" or vice versa. Example: ALSA forwards to PulseAudio using libasound_module_pcm_pulse; PulseAudio forwards to JACK using module-jack-{sink,source}.
3. A direct route is neither here nor there, but a multi-hop route is still feasible (example: OSS Proxy -> PulseAudio -> ALSA).
I go through a significant amount of theorizing to argue why it is desirable to have such a configuration, and then make an attempt at actually defining and explaining how to setup such a configuration, on my blog: http://tiyukquellmalz.org/blogs/blog5.php/2009/08/23/dreaming-of-universal-audio-stacks
I just want to add that I am neither pro-PulseAudio nor anti-PulseAudio. There are applications that use the PulseAudio API particularly well -- for instance, Gstreamer and Skype 2.1 Beta. For these apps, PulseAudio works very well, so I see no reason to exclude PulseAudio from my sound stack. As long as it is useful, I will include it as part of my sound stack. _Part Of_. The other parts are designed to take care of audio APIs and use cases that PulseAudio alone cannot handle. Unless Lennart wants to implement every last audio API under the sun natively in Pulseaudio as a module, just as he did with ESD, then I don't think I will ever arrive at a situation where PulseAudio -> ALSA is the full extent of my sound stack -- especially not while popular apps out there still use APIs of JACK, OSS, etc.
Max, I also like to play around with stuff, and I feel your pain that Foo Application has a relatively poor chance of using the APIs that your sound stack supports. But, there are actually very many ways to allow applications to use different audio APIs at the same time, in parallel, by chaining together multiple APIs or sound servers. This is worst solution in terms of performance, but the best solution in terms of compatibility. With the right configuration, 99% of sound-using apps will "just work", regardless of what API they use.
Check out my recent-ish blog article on this: http://tiyukquellmalz.org/blogs/blog5.php/2009/08/23/dreaming-of-universal-audio-stacks