Capable has nothing to do with carrier appetite. Carriers want to control and build their own silos complete with lock-in, nothing about "he we can run android apps too, but with 10x the number of OS versions and 20x the number of device devices to support" makes good business sense for a carrier.
Indeed, clearly higher European tax rates lead to a better recirculation of the wealth and overall fiscal health superior to the US. Unless you actually look at the data. Belgium, Ireland, the UK Spain, Portugal and Greece all have higher private debt defaults than the US as a percentage of GDP, Germany is statistically equivalent. All of those states aside from Germany, despite higher taxes have a higher debt to GDP ratio and again, Germany is roughly equivalent. The Europeans may "love" their higher taxes, but they aren't any better at controlling their spending or debt, quite the opposite.
http://online.wsj.com/article/SB10001424052748704140104575056751636031606.html
This may be true for Java.
It isn't true for C/C++.
With C/C++ and NPTL, the many-thread blocking IO style yields slightly lower latency at low IO rates, but offers significant latency variability and sharply decreased thruput at higher IO rates.
It seems that the linux scheduler is much to blame for this-- the number of times that a thread is scheduled on a different CPU increases dramatically with more threads, and this trashes the caches.
I've seen order-of-magnitude decreases in performance and order-of-magnitude increases in latency as a result of what appears to be the cache trashing.
I've seen similar arguments against using hyper-threading with Java.
Curious, have you tried limiting the number of threads to prevent the thrashing or a pbind equivalent to keep a thread closer to a cache pipeline?
Honestly, the MF has bigger issues they should be focused on. If they were killing it, Chrome wouldn't even make the front page. Bloat continues to overtake their software and they're being out-engineered by smaller teams backed by big companies. They should turn their attention inwards first and worry about Chrome second.
Small to mid-sized shops who get by with less than a dozen SAs and who don't have WAN volume replication concerns might go this route, but there is too much risk for Fortune 500. It mostly boils-down to 3rd party applications, hardware and drivers. If you're a F500, you probably have proprietary storage of some sort and you probably rely on volume replication across the WAN. You want to hook into that storage from Linux, you need a "certified" platform and that ain't going to be an arbitrary set of Ubuntu packages. Sure it will probably work from Ubuntu, until you get kernel panics under load. Then your in-house Linux "experts" call support for the storage vendor and they ask what distro version and driver you're using. When you say "Gutsy Gibbon recent" they laugh and refuse to support you. At that point, your idea of community support doesn't look quite so hot considering nobody in the community can repro your hardware/driver issue.
Mod parent down please.
"The present situation for US IT workers is much better now, than it will be five years from now." - chances are you can find someone making this exact quote in 2001 and it turned out to be false. I'm guessing the OP works for Gartner, else they would actually understand that there might be some skill or value to the experience sitting behind that keyboard.
Sorry, those application servers will have to wait until Apache mpm-worker is done destroying mpm-prefork benchmarks. Sheesh, I guess all those developers working on the most popular, successful Web server ever have a lot of learning to do.
Threads have been a far more efficient way to write socket-based servers for decades. Or, perhaps now you plan to re-write history and know something the late, great R. Stevens didn't. Suggest the OP read his detailed analysis and benchmarks starting here:
The argument that the OS is more secure would carry a bit more weight if the OpenBSD team didn't blatantly try to deny that this was a vulnerability as the release states. If you buy the release, Core made them look pretty bad, as if they just dismissed the disclosure effectively saying "we don't think that's a problem". When they did that, Core dropped it right on them, then they reacted. If the team were as security conscious as you claim, they wouldn't have simply dismissed it and would have given the issue more serious consideration.
I've always thought of the BSDs (Net and Open anyway) as a smaller attack vector, nothing inherently more secure. They don't have a monopoly on smart developers and all humans make mistakes.
Well, there is absolutely, positively nothing AJAX-specific about what this paper describes. Despite it's ignorance about AJAX being a framework, the paper does point out some realistic concerns about XSS. Unfortunately, those same techniques could be used to subvert regular HTTP GET/POST as well as fancy-pants XHRs. There is nothing uniquely AJAX about this save the authors' attempt to capitalize on trendy terms vis-a-vi their consulting firm.
BTW, fantastic job description, mind if I use this for my own postings?
"Senior Security Engineer of proved experience, works since many years as an IT consultant for private and public companies."
Eh, I'm a bit confused by the myriad of APIs available for google, but doesn't he Base data API provide the same features, just over their REST/ATOM feeds? With my key these still work quite nicely, don't use SOAP and aren't depricated:
http://code.google.com/apis/base/samples/python/py thon-sample.html
Re:Don't get me wrong
on
Free Geek Robbed
·
· Score: 2, Informative
To install Windows, we would have to move to installing from master CDs, which we would then have to keep under lock and key
Sorry, this is blatently false. Windows installs across a network in "unattended" mode very similar to Kickstart or AutoYAST. In fact, all three can be installed on a common infrastructure of ISC DHCP and TFTP for the PXE portion of things and Samba for media. Provisioning Windows using OSS tools has been around for many years. You are mostly right about licenses, but this detail is an exaggeration.
This really sucks that this happened to you guys, I'll see what I can dig-up and bring by to help out.
That's not entirely true. Even songs you purchase through the service have DRM that expires every year. You still need to have your lease renewed once a year (I think, not sure on the exact timeframe as support was vague on this) by calling home to the master blaster. You never truly own it.
After once happily installing to x64, the Yahoo! music engine no longer works on this architecture/OS despite having been a mainstream Microsoft release for over a year now. There isn't really any support for their music product line aside from a pittance of online help pages. It's a bit offensive to me as someone locked into x64 to hear that they are working away so hard when they lag behind their compeditors on entire platforms while not acknowledging their lack of support for x64 on their product web site.
They are leaving Portland although their kit is still at this location, I've heard that they took venture $$$ and are moving to CA. Sort of supports the OP I guess.
Unless, of course, you set the system clock from the BIOS. In which case, it uses local time. Note that you DON'T set a timezone in the BIOS, which would be the case if it was meant to store UTC.
I can argue the same thing, that because there is no timezone in the BIOS, that it's meant to store UTC and that the OS is meant to interpret locales accordingly. By your logic, we should also store number formatting, currency symbols and date formats in the BIOS. We could put everything geographic-specific on the ROM. Or, we could use a global standard for measuring time and let the software figure out what the local time is. I choose the latter, unfortunately Microsoft makes it impossible.
Nothing good comes from storing local time in the BIOS. Windows could easily keep the local TZ in the registry and adjust from UTC on the system clock, just like every other modern OS known to man. Bad things, however, do come of it. Namely that it makes dual booting more difficult. Speaking from first hand experience, when you travel with a dual-boot rig and Windows keeps borking the system clock, it's really annoying to have to change the Unix local time relative to a system clock that is set to some unknown timezone. You are blindly defending Microsoft and overlooking the simple fact that it does more harm than good.
Apparently, our ideas of good are not the same. I for one, am not concerned with Windows 3.1 backward compatibility. Secondly, if someone is setting their BIOS clock, they should damn well be able to figure out the difference between system time and local time. Anyone who cracks into their BIOS ought to know what they are doing and should live with any changes they make. Even if a user doesn't understand the difference, Microsoft is effecively saying, hey, we know better than you and we are going to undo your changes to help you out. That's a crock. If I change something, I do it for a reason and that reason is usually because I want it that way, not because I'm to outguess my operating system.
No, the system clock uses what the OS tells it to. Every OS known to man except Microsoft, when configured properly, uses UTC as their system time.
I choose to live with options, adherence to standards and best practices, not what any single company tells me I should do, especially with hardware that I own. You may choose to live with it, some of us don't. Live with that.
Then you've never done anything but "played". The system clock for all *nix servers (and arguably desktops) should always be UTC with the local time set accordingly. Unless you live somewhere that your are in the UTC-0 locale, dual booting will hoze this by taking over the system clock and setting it to localtime.
They can't even get the atomic clock right. The OS sets your hardware clock adjusted with the local time zone offset pretty much borking anything else that needs to reference it and bucking the trend of every other hardware vendor and every other OS known to man. No other OS on the planet is so bold to assume it's the only thing running on the hardware and that it should do whatever it wants with the hardware.
Drone on, nothing to see here.
They are not the same even if they do use similar kernels.
This is probably one of the most misunderstood things about OSX. OSX uses a mach kernel, not a BSD kernel
http://en.wikipedia.org/wiki/Mach_kernel/
OSX as an OS does use many of FreeBSD's utilities making the OS as a whole similar but the brain, the kernel is different.
Maybe they are trying to live up to that old "unbreakable" campaign. If they don't release any patches, it's tough to break anything.
If you think this applies to just their database software, think again. I've had Oracle ship me gold cut CDs for their OAS app server on several occasions and have seen Oracle Finanaicals implementations go through over 1000 patches over the course of a year.
As far as I know, both cygwin and Services for Unix only runs on Windows:)
All jokes aside, when I'm forced to use Windows for productivity (not gaming which is the only time I choose to use Windows), cygwin is invaluable. I hear the new monad shell is much better than the crappy old cmd.exe
Slashdot Mirror
Capable has nothing to do with carrier appetite. Carriers want to control and build their own silos complete with lock-in, nothing about "he we can run android apps too, but with 10x the number of OS versions and 20x the number of device devices to support" makes good business sense for a carrier.
Indeed, clearly higher European tax rates lead to a better recirculation of the wealth and overall fiscal health superior to the US. Unless you actually look at the data. Belgium, Ireland, the UK Spain, Portugal and Greece all have higher private debt defaults than the US as a percentage of GDP, Germany is statistically equivalent. All of those states aside from Germany, despite higher taxes have a higher debt to GDP ratio and again, Germany is roughly equivalent. The Europeans may "love" their higher taxes, but they aren't any better at controlling their spending or debt, quite the opposite. http://online.wsj.com/article/SB10001424052748704140104575056751636031606.html
This may be true for Java. It isn't true for C/C++.
With C/C++ and NPTL, the many-thread blocking IO style yields slightly lower latency at low IO rates, but offers significant latency variability and sharply decreased thruput at higher IO rates. It seems that the linux scheduler is much to blame for this-- the number of times that a thread is scheduled on a different CPU increases dramatically with more threads, and this trashes the caches. I've seen order-of-magnitude decreases in performance and order-of-magnitude increases in latency as a result of what appears to be the cache trashing.
I've seen similar arguments against using hyper-threading with Java. Curious, have you tried limiting the number of threads to prevent the thrashing or a pbind equivalent to keep a thread closer to a cache pipeline?
Is it me or is Mailinator a blatant rip-off of http://spamgourmet.com/?
Honestly, the MF has bigger issues they should be focused on. If they were killing it, Chrome wouldn't even make the front page. Bloat continues to overtake their software and they're being out-engineered by smaller teams backed by big companies. They should turn their attention inwards first and worry about Chrome second.
Small to mid-sized shops who get by with less than a dozen SAs and who don't have WAN volume replication concerns might go this route, but there is too much risk for Fortune 500. It mostly boils-down to 3rd party applications, hardware and drivers. If you're a F500, you probably have proprietary storage of some sort and you probably rely on volume replication across the WAN. You want to hook into that storage from Linux, you need a "certified" platform and that ain't going to be an arbitrary set of Ubuntu packages. Sure it will probably work from Ubuntu, until you get kernel panics under load. Then your in-house Linux "experts" call support for the storage vendor and they ask what distro version and driver you're using. When you say "Gutsy Gibbon recent" they laugh and refuse to support you. At that point, your idea of community support doesn't look quite so hot considering nobody in the community can repro your hardware/driver issue.
Mod parent down please. "The present situation for US IT workers is much better now, than it will be five years from now." - chances are you can find someone making this exact quote in 2001 and it turned out to be false. I'm guessing the OP works for Gartner, else they would actually understand that there might be some skill or value to the experience sitting behind that keyboard.
The "Black Screen of Death" I get on my nVidia GTX8800 says "no" - it's not ready for the masses nor is bullet-proof Xorg config functioning properly.
Eh, maybe a working web site? Nexenta's site has been down for three days now.
Sorry, those application servers will have to wait until Apache mpm-worker is done destroying mpm-prefork benchmarks. Sheesh, I guess all those developers working on the most popular, successful Web server ever have a lot of learning to do.
l -Networking/dp/0131411551/ref=pd_bbs_sr_1/104-5537 299-2831938?ie=UTF8&s=books&qid=1174574811&sr=8-1
Threads have been a far more efficient way to write socket-based servers for decades. Or, perhaps now you plan to re-write history and know something the late, great R. Stevens didn't. Suggest the OP read his detailed analysis and benchmarks starting here:
http://www.amazon.com/Unix-Network-Programming-Vo
The argument that the OS is more secure would carry a bit more weight if the OpenBSD team didn't blatantly try to deny that this was a vulnerability as the release states. If you buy the release, Core made them look pretty bad, as if they just dismissed the disclosure effectively saying "we don't think that's a problem". When they did that, Core dropped it right on them, then they reacted. If the team were as security conscious as you claim, they wouldn't have simply dismissed it and would have given the issue more serious consideration. I've always thought of the BSDs (Net and Open anyway) as a smaller attack vector, nothing inherently more secure. They don't have a monopoly on smart developers and all humans make mistakes.
Well, there is absolutely, positively nothing AJAX-specific about what this paper describes. Despite it's ignorance about AJAX being a framework, the paper does point out some realistic concerns about XSS. Unfortunately, those same techniques could be used to subvert regular HTTP GET/POST as well as fancy-pants XHRs. There is nothing uniquely AJAX about this save the authors' attempt to capitalize on trendy terms vis-a-vi their consulting firm. BTW, fantastic job description, mind if I use this for my own postings? "Senior Security Engineer of proved experience, works since many years as an IT consultant for private and public companies."
Eh, I'm a bit confused by the myriad of APIs available for google, but doesn't he Base data API provide the same features, just over their REST/ATOM feeds? With my key these still work quite nicely, don't use SOAP and aren't depricated: http://code.google.com/apis/base/samples/python/py thon-sample.html
Sorry, this is blatently false. Windows installs across a network in "unattended" mode very similar to Kickstart or AutoYAST. In fact, all three can be installed on a common infrastructure of ISC DHCP and TFTP for the PXE portion of things and Samba for media. Provisioning Windows using OSS tools has been around for many years. You are mostly right about licenses, but this detail is an exaggeration.
This really sucks that this happened to you guys, I'll see what I can dig-up and bring by to help out.
That's not entirely true. Even songs you purchase through the service have DRM that expires every year. You still need to have your lease renewed once a year (I think, not sure on the exact timeframe as support was vague on this) by calling home to the master blaster. You never truly own it.
After once happily installing to x64, the Yahoo! music engine no longer works on this architecture/OS despite having been a mainstream Microsoft release for over a year now. There isn't really any support for their music product line aside from a pittance of online help pages. It's a bit offensive to me as someone locked into x64 to hear that they are working away so hard when they lag behind their compeditors on entire platforms while not acknowledging their lack of support for x64 on their product web site.
They are leaving Portland although their kit is still at this location, I've heard that they took venture $$$ and are moving to CA. Sort of supports the OP I guess.
Nothing good comes from storing local time in the BIOS. Windows could easily keep the local TZ in the registry and adjust from UTC on the system clock, just like every other modern OS known to man. Bad things, however, do come of it. Namely that it makes dual booting more difficult. Speaking from first hand experience, when you travel with a dual-boot rig and Windows keeps borking the system clock, it's really annoying to have to change the Unix local time relative to a system clock that is set to some unknown timezone. You are blindly defending Microsoft and overlooking the simple fact that it does more harm than good.
Then you've never done anything but "played". The system clock for all *nix servers (and arguably desktops) should always be UTC with the local time set accordingly. Unless you live somewhere that your are in the UTC-0 locale, dual booting will hoze this by taking over the system clock and setting it to localtime.
They can't even get the atomic clock right. The OS sets your hardware clock adjusted with the local time zone offset pretty much borking anything else that needs to reference it and bucking the trend of every other hardware vendor and every other OS known to man. No other OS on the planet is so bold to assume it's the only thing running on the hardware and that it should do whatever it wants with the hardware. Drone on, nothing to see here.
Maybe they are trying to live up to that old "unbreakable" campaign. If they don't release any patches, it's tough to break anything.
If you think this applies to just their database software, think again. I've had Oracle ship me gold cut CDs for their OAS app server on several occasions and have seen Oracle Finanaicals implementations go through over 1000 patches over the course of a year.
As far as I know, both cygwin and Services for Unix only runs on Windows :)
All jokes aside, when I'm forced to use Windows for productivity (not gaming which is the only time I choose to use Windows), cygwin is invaluable. I hear the new monad shell is much better than the crappy old cmd.exe