Because converting packages to different systems doesn't deal with the dependency hell found in most non-trivial Linux applications. The location of the binaries is actually the least of your concerns.
Having multiple copies of shared libraries is bad for the system memory profile, not to mention bad for leaving lingering bugs long after they have been fixed in the library's mainline code.
Depends on how much you are not sharing. If the OS base is strong enough and you only need to bundle minor auxiliary libraries with your app, it isn't a big deal. And even if you do package a bugged library with your application, it may not matter. The bug may not even apply to yoru application. As long as your application works and the bug isn't security related, there's no problem.
Which is why a solo approach to dependency management has sever limitations. Distros may have messy process, but they are on the right track in that a lot of collaboration, and the tools to make it smooth, is needed to do things right.
I have to strongly disagree. As an end user of LInux on the desktop for 12+ years and OS X for almost 4 now, I can honestly say that the OS X model kicks ass. I hate feeling straight jacketted by a centralized package system on a desktop system. I know that in theory a good central repository should be better, but in practice the.app model found on OS X is superior. It is bad enough that I have to rely on Macports for my commandline stuff. I dont' want that to leak into my desktop app experience.
Everything you say applies to servers, not desktop end users. As a user, I most certainly do want to latest and greatest. In fact, that's what always made using Linux on the desktop so frustrating for me. I felt so straight jacketted by centralized package management.
Now libsnmp is found to have a bug. Linux users update libsnmp. Apple users... well, you have to rebuild MacMailGarbage.app with the new libsnmp, put it in the v1.04.app, and ship it to your users. If you don't, then MacMailGarbage.app can be hacked by sending a deformed HELO from the server, executing malware on the user's machine.
You're assuming that Apple does not include such basic libraries in the OS. They do. It isn't normally an issue.
Now libssl has a security hole. If you don't release a new version of MacMailGarbage.app, your users will be susceptible to rogue SNMP connections, possibly by a MitM.
Again, SSL is a basic OS X API.
Now libpng has a security hole. Again, Linux users update libpng. Mac users have to update...
And again, PNG support is built into OS X. Not an issue. I understand your point in general, but 3 of the 3 examples you gave off the top of your head are not really issues at all. In practice, this is not a major concern for OS X developers or users.
As far as I am concerned,.app software packaging is a HUGE advantage that OS X has over both WIndows and Linux. I would not trade it away. It is one of those things that keeps me using OS X.
If the operating system base you're installing on is stable and broad enough such that few libraries need be packaged with the user intalled application, then it is really not that much of an issue, like on OS X. But Linux is just too fragmented for it to really work. There's the LSB, but I don't think it is strong enough.
As you say, it's a solved problem, if the programmers use it. And parameterized queries absolutely protect those particular queries from the malicious bastards, so I'm not knocking them in any way. I'm just saying that someone shouldn't naïvely claim "we're secure" based solely on that premise.
I think that goes without saying. The GP just said that SQL injection is a solved problem.
I think you'd have to know what the max voltage was for that kind of capacity and the application. I'll take a stab at it even though my last electronics class was like 15 years ago. Lets assume a 48V system like you might have in an electric vehicle.
At 48V, you could store 4,800,000 Coulombs of charge. If E = Q x V, that means you have 230,400,000 Joules of energy and 1 kWh = 3.6 x 10^6 J. So you have 64 kWh/kg. That seems too good to be true though. It is quite possible that such capacitors couldn't handle a potential of 48V. If we're talking more like 12V, then the capacity goes way down to 4 kWh/kg, which is still pretty good compared to Li ion batteries.
Besides voltage rating, you have to consider leakage. Such an ultra capacitor may leak charge at a significant rate, making it less that desirable for anything requiring longer term storage.
It is going to cost you more and be much more of a pain in the ass to host your own physical WIndows server than it will to get a virtual server in the "cloud," so yeah, this isn't really optional. Trust me, you don't want to have to worry about babysitting your server in a collocation facility. Plus, it simply will not scale. Before you get even 1/2 of the way to the point of millions of users, you'll have a staff and at least one full time admin,w/ dedicated database server, applicaiton servers, load balancers, etc.
Though it sounds like you're getting way ahead of yourself. Just worry about getting your site out there for now. Get a virtual server.
To be fair, it is possible to break things that way. So the approach is not necessarily unreasonable. Of course, there are plenty of things you could experiment with without much risk, but you can't always know what those things are, especially if you're technically illiterate to begin with. I think it comes down to how much time you're willing to invest in fixing stuff when your experimentation does break things. If you're like me, fixing things when I break them is half the fun. For others, it just keeps them from doing what they want to do.
Indeed, USB is still useful (even on Macs) for low speed devices like keyboards and mice. That's where USB has really been useful for me, anyway. I always tried to avoid it for things like mass storage.
I guess I just don't have a head for business but I just can't imagine how these sites are worth so much money. Of course, I also wonder why advertising in general is able to bring in so much money.
I've been in many situations where that doesn't fix it. In some Linux terminals it would completely screw up the text, turning everything a garbled mess.
I'm pretty sure you DON'T actually want to see the bytes of a PNG on your terminal. I've ruined countless terminal sessions by accidentally catting binary.
Maybe if it could emulate a plain color terminal so I could run things like vi, screen, etc. But only being able to type commands seems a little restrictive.
My first impression of PowerShell was that it was too much of a programming language and not enough of a shell. Similar to the a Ruby on Rails application console. Great access to the internals with application objects, arrays, hashes, regular expressions, etc, but pulling in data from outside is kind of a pain. I dunno though, I never cared to use Windows enough to figure PowerShell out.
Not a big deal since there's not a lot of OS X business apps anyway. You can run an RDP client on OS X. I've done that in a corporate environment and it works fine. You just can't have OS X "thin" clients, but then.. why would you want to?
And lose X support? Unable to run that one KDE application you need or basic applications like Firefox? I don't think so. It ain't gonna happen. Linux desktop apps are just too fragmented. X11 is the only thing holding it all together. Remove X11 and Linux on the desktop is dead. Ok, you could probably write an X server that uses GNOME instead of the other way around like OS X does, but that sucks form a user perspective. I hate running X11 on my Mac. I can do it, but it is a last resort. Applications just don't work right in that mode. It is like running stuff in Parallels/VMWare on a different platform, which I also try to avoid when I can.
Slashdot Mirror
Why has no one done this yet?
Because converting packages to different systems doesn't deal with the dependency hell found in most non-trivial Linux applications. The location of the binaries is actually the least of your concerns.
Having multiple copies of shared libraries is bad for the system memory profile, not to mention bad for leaving lingering bugs long after they have been fixed in the library's mainline code.
Depends on how much you are not sharing. If the OS base is strong enough and you only need to bundle minor auxiliary libraries with your app, it isn't a big deal. And even if you do package a bugged library with your application, it may not matter. The bug may not even apply to yoru application. As long as your application works and the bug isn't security related, there's no problem.
Which is why a solo approach to dependency management has sever limitations. Distros may have messy process, but they are on the right track in that a lot of collaboration, and the tools to make it smooth, is needed to do things right.
I have to strongly disagree. As an end user of LInux on the desktop for 12+ years and OS X for almost 4 now, I can honestly say that the OS X model kicks ass. I hate feeling straight jacketted by a centralized package system on a desktop system. I know that in theory a good central repository should be better, but in practice the .app model found on OS X is superior. It is bad enough that I have to rely on Macports for my commandline stuff. I dont' want that to leak into my desktop app experience.
Everything you say applies to servers, not desktop end users. As a user, I most certainly do want to latest and greatest. In fact, that's what always made using Linux on the desktop so frustrating for me. I felt so straight jacketted by centralized package management.
Now libsnmp is found to have a bug. Linux users update libsnmp. Apple users ... well, you have to rebuild MacMailGarbage.app with the new libsnmp, put it in the v1.04 .app, and ship it to your users. If you don't, then MacMailGarbage.app can be hacked by sending a deformed HELO from the server, executing malware on the user's machine.
You're assuming that Apple does not include such basic libraries in the OS. They do. It isn't normally an issue.
Now libssl has a security hole. If you don't release a new version of MacMailGarbage.app, your users will be susceptible to rogue SNMP connections, possibly by a MitM.
Again, SSL is a basic OS X API.
Now libpng has a security hole. Again, Linux users update libpng. Mac users have to update...
And again, PNG support is built into OS X. Not an issue. I understand your point in general, but 3 of the 3 examples you gave off the top of your head are not really issues at all. In practice, this is not a major concern for OS X developers or users.
As far as I am concerned, .app software packaging is a HUGE advantage that OS X has over both WIndows and Linux. I would not trade it away. It is one of those things that keeps me using OS X.
If the operating system base you're installing on is stable and broad enough such that few libraries need be packaged with the user intalled application, then it is really not that much of an issue, like on OS X. But Linux is just too fragmented for it to really work. There's the LSB, but I don't think it is strong enough.
As you say, it's a solved problem, if the programmers use it. And parameterized queries absolutely protect those particular queries from the malicious bastards, so I'm not knocking them in any way. I'm just saying that someone shouldn't naïvely claim "we're secure" based solely on that premise.
I think that goes without saying. The GP just said that SQL injection is a solved problem.
I guess I meant from a code perspective. I suppose there are plenty of other ways to leave your system wide open. /shrug
The most preventable of all security holes. How sad.
I think you'd have to know what the max voltage was for that kind of capacity and the application. I'll take a stab at it even though my last electronics class was like 15 years ago. Lets assume a 48V system like you might have in an electric vehicle.
At 48V, you could store 4,800,000 Coulombs of charge. If E = Q x V, that means you have 230,400,000 Joules of energy and 1 kWh = 3.6 x 10^6 J. So you have 64 kWh/kg. That seems too good to be true though. It is quite possible that such capacitors couldn't handle a potential of 48V. If we're talking more like 12V, then the capacity goes way down to 4 kWh/kg, which is still pretty good compared to Li ion batteries.
Besides voltage rating, you have to consider leakage. Such an ultra capacitor may leak charge at a significant rate, making it less that desirable for anything requiring longer term storage.
1kg, duh ;-)
It is going to cost you more and be much more of a pain in the ass to host your own physical WIndows server than it will to get a virtual server in the "cloud," so yeah, this isn't really optional. Trust me, you don't want to have to worry about babysitting your server in a collocation facility. Plus, it simply will not scale. Before you get even 1/2 of the way to the point of millions of users, you'll have a staff and at least one full time admin,w/ dedicated database server, applicaiton servers, load balancers, etc.
Though it sounds like you're getting way ahead of yourself. Just worry about getting your site out there for now. Get a virtual server.
If you push a button labeled "Alarm," you will set off an alarm, obviously.
To be fair, it is possible to break things that way. So the approach is not necessarily unreasonable. Of course, there are plenty of things you could experiment with without much risk, but you can't always know what those things are, especially if you're technically illiterate to begin with. I think it comes down to how much time you're willing to invest in fixing stuff when your experimentation does break things. If you're like me, fixing things when I break them is half the fun. For others, it just keeps them from doing what they want to do.
Indeed, USB is still useful (even on Macs) for low speed devices like keyboards and mice. That's where USB has really been useful for me, anyway. I always tried to avoid it for things like mass storage.
MacBook Air doesn't have Firewire and I've heard a other recent Macbooks don't either. Sucks if you ask me.
Doesn't always work.
Value for whom, though? How does LinkdIn directly benefit from you having a professional network?
I guess I just don't have a head for business but I just can't imagine how these sites are worth so much money. Of course, I also wonder why advertising in general is able to bring in so much money.
I've been in many situations where that doesn't fix it. In some Linux terminals it would completely screw up the text, turning everything a garbled mess.
Great, so now I have The Matrix scrolling on my screen....
I'm pretty sure you DON'T actually want to see the bytes of a PNG on your terminal. I've ruined countless terminal sessions by accidentally catting binary.
Maybe if it could emulate a plain color terminal so I could run things like vi, screen, etc. But only being able to type commands seems a little restrictive.
My first impression of PowerShell was that it was too much of a programming language and not enough of a shell. Similar to the a Ruby on Rails application console. Great access to the internals with application objects, arrays, hashes, regular expressions, etc, but pulling in data from outside is kind of a pain. I dunno though, I never cared to use Windows enough to figure PowerShell out.
Not a big deal since there's not a lot of OS X business apps anyway. You can run an RDP client on OS X. I've done that in a corporate environment and it works fine. You just can't have OS X "thin" clients, but then.. why would you want to?
And lose X support? Unable to run that one KDE application you need or basic applications like Firefox? I don't think so. It ain't gonna happen. Linux desktop apps are just too fragmented. X11 is the only thing holding it all together. Remove X11 and Linux on the desktop is dead. Ok, you could probably write an X server that uses GNOME instead of the other way around like OS X does, but that sucks form a user perspective. I hate running X11 on my Mac. I can do it, but it is a last resort. Applications just don't work right in that mode. It is like running stuff in Parallels/VMWare on a different platform, which I also try to avoid when I can.