Proper anonymous functions, including lambdas. Proper function pointers (called delegates) without needing to write entire classes for them. Support for stack-allocated complex types (structs). Support for bi-directional and output parameters, even of types normally passed by value. Unsigned integer types. Object parameters (technically functions, but cleaner than a bunch of Get*and Set* function definitions and usages). Proper generics (try declaring an array of generic type in Java, for example). Easy interop with native code (P/Invoke, good marshaling capabilities, support for ordered structs and unsigned types, etc.). Support for direct memory access (if you want/need it; use the unsafe keyword and byte* or similar types). LINQ. Tuples. No one-public-class-per-source-file restriction, or the associated restriction on file name. No restriction on project directory structure. Partial classes (allows separating parts of the same class, such as autogenerated code from developer code, into different files). The using keyword (in both of its uses). Conditional compilation (similar to C preprocessor) to do things like exclude debug code without any overhead at all.
These are the ones that came to mind in just a few minutes of thinking about it, based on personal experiences, I'm sure there's a ton more. C# is a vastly more advanced language than Java. I don't deny that MS learned heavily from Java, but half of that learning was "let's not repeat their mistakes" and the other half was "what is it really lame that this language lacks? Let's do better."
How exactly do you propose that Google kick Amazon out of the Open Handset Allienace when Amazon is not, never has been, and is not trying to be a member of the OHA? Your post is ludicrous.
It should be noted that it won't affect Alibaba or Asus's ability to use the Android codebase, just Google won't be working with them in the future.
Amazon has been doing this from the beginning; using the Android codebase as a starting point and releasing a product using their derived version of Android, without any Google support or any of the otehr advantages that OHA members get. They're doing fine, too... but they aren't making a smartphone.
I don't personally support the current patent system, but the answer to your question is blindingly obvious: because if you can't put restrictions on the use of the algorithm, your competitors are going to come along, and use it themselves without either incurring the R&D cost or compensating your for it. Thus they're able to offer competing products at a lower cost, making computer science R&D a counter-productive strategy to running a competitive business (i.e. stifling innovation). Patents are supposed to be the solution to this problem.
Practically speaking, the current system is just broken. The basis of it is important, but the way it's being used is extremely harmful.
Windows Mobile bears absolutely no resemblence to Windows Phone, especially not to WP8, and that includes the design decisions. I get what you're saying about them continually trying for a unified interface, though.
WTF do you mean, Surface was never released? I've seen at least four of them in the wild. They cost a crapload, so they weren't as popular as they might have been, but they definitely exist.
Also, they gave all employess WP7 devices too; the addition fo the Surface is new this time around but the idea of "new product; everybody gets one!" isn't even new within phones for MS.
60' is "a boat that small" to you? People routinely cruise the world on monohulls that are 40' or less. I'm guessing you have either very little, or very strange, blue-water experience.
That said, there are a few things to keep in mind. You want a *lot* of redundency in some systems, like GPS and radio. Get at least two handheld VHF radios. Get at least two mounted GPS receivers, plus a handheld (two if you make a ditch bag, and on a monohull you should; put an extra VHF in here too of course) and probably at least one for your PC (USB interface). If you have a smartphone, that's one more (which is good), not a replacement for one of the others. Carry a ton of spare batteries.
A watermaker is a huge improvement to the cruising experience. As long as it keeps working, you don't have to go on severe water rationing during ocean passages and you can avoid the hassle of tying up to take on water all the time. DC-driven ones are best if you're going with solar panels and/or a wind turbine, but if you're going to have a generator, hook the watermaker up to that (ideally directly, although via AC wiring works too).
Energy independence, usually via photovoltaics and/or wind, is a marvelous thing. Consider making an energy budget (there are charge controlers that will monitor battery state and flow in both directions for you; these help a lot). Make sure you charge a "house" battery separately from the engine battery; it's great to have the ability to connect them, but don't do it by default.
Make sure there's a way to get water out of the tanks (for example, a foot or hand pump) in case of a power (or powered pump) failure.
A good quad-band SIM-unlocked 3G modem is a wonderful thing. Most parts of the world now offer cellular Internet service, often good enough for Skype. A smartphone may also work, if it's got an easy way to tether.
Lots of other advice, but it's late and I'm tired. Go check out http://svocelot.com/ for a lot more info; my family has been cruising for over ten years on the current boat, and did so for seven years back in the 80s as well.
Personal history (3.5 years of blue-water cruising, 12K+ sea miles) suggests you're safer without one anyhow. The people we heard of getting shot were either the ones who pulled a gun on their boarders, or who had a guun on board when the boarders snuck on at night (the boarders found the gun, shot the owner, and left).
"Pirates" in the usual sense aren't really the problem. The much bigger problem is people sneaking onto your boat while you're either away or asleep, and stealing things. They aren't always armed, but if they are, going for your own gun probably won't help, and if they aren't, they may find your gun before you can get to it.
Incidentally, dinghies are the first to go; use a steel cable or chain and haul the dingy out of the water at night. Make sure the outboard is *very* well secured, as well; a strong and high-quality stainless steel padlock works well, but remember that a hacksaw can get through that too. Unlike pirates, which can generally be avoided just by having some caution rgarding what parts of the world you sail, boarders are more-or-less a risk everywhere; consider investing in a simple motion sensor alarm for the rougher areas.
Oh, for anybody who is curious, my family's website: http://svocelot.com/ . Check out the section devoted to the boat gear in particular (for relevance to this Ask Slashdot).
If you're actually going blue-water cruising, go with PACTOR (v3 or better). The speed jump will matter a *LOT* (for things like pulling down GRIB files with decent area and detail, you'll want all the bandwidth you can get). Downloading 50K or more is reasonable with PACTOR3 (what we used when I was cruising); try that over WINMOR and you'll probably be kicked off the ground station or lose propagation first.
Sailmail is all right, and certainly better than nothing. For most purposes, Winlink 2000 is better; the ground stations are less crowded and you can connect for longer periods of time, plus most of them support faster PACTOR connections. You do need a HAM licence high enough to use the HF bands (so, General class), and of course a compatible radio and modem (get something capable of PACTOR3, unless they've introduced a newer, better variant). You also can't legally use HAM radio (and thus, can't use Winlink) to discuss business, so if you expect to need that, Sailmail might be better. For most cruisers that's no problem, though.
I'm not going to recommend radio gear - the boat I lived on uses an Icom 706mk2g, which is a great little 100W radio aside from needing an external tuner, but that was some 11 years ago. Antennas bear thinking about though. Random wire actually works fine, so long as you get it high enough, have a good enough antenna tuner, and a good enough ground. Dipoles work better, but only for specific bands; you'll want to think carefully about that. Directional antennas are generally poinless on a sailboat; even if you can mount one, you can't keep it pointed the right way.
Also, consider the radio environment. Any RF sources on the boat, such as alternators (engine, generator, windcharger, etc.) or DC-DC voltage-converters (such as for solar panels or a laptop charger) are going to play havoc with your reception for either voice or data. You can get RF-insulated DC voltage converters suitable for use with a laptop online, though. You'll also need a good set of ferrite chokes; most consumer electronics either have insufficient chokes or none at all. This will result in those electronics going crazy (mouse dancing all over the screen and clicking random things, for example) if you key a powerful HF radio nearby.
Where the fuck did this " 52' " thing come from? I mean, I'm used to Americans not knowing how to use Metric, but I expected at least basic competency in math. A meter is *more* than three feet. Thus, 18m > 54' i.e. longer than 52' (it's actually close enough to 60' for rounding error).
iOS6 is supported all the way back to the iPhone 3GS. How is this creating any fragmentation?
Except, that's not really true. Some features of iOS 4, 5, and 6 were backported to the old hardware, and the version number was incremented, but a number of the defining features aren't present at all, or are crippled.
Siri is an obvious example; it's a software feature (there's some hardware in the newer iPhones that improves the experience, but the feature itself is pure software) that doesn't even put much strain on the local capabilities of the device, yet it's not available for the 3GS.
Then there's app fragmentation. Apps written for the "retina" resolution aren't going to work on a 3GS. Apps written for the new 16:9 resolution aren't even going to work on a 4S. Android designed around this problem from the beginning (although it was an issue with Windows Mobile, before that OS was EoLed).
iOS is less fragmented than Android, sure. But it's definitely still fragmented, and new releases that change things like aspect ratio aren't going to help.
You badly, badly misremember the awfulness of MySpace. Please don't make me post this more than once, the memories are painful...
Embedded Flash objects in the page. Lots of them. All set to auto-play when the page loads. Facebook doesn't allow embedding arbitrary content, and doesn't allow auto-playing video on your page either.
Incredibly atrocious CSS, like text that ballooned to 40pt on hover or that was in incredibly unreadable fonts, or covered up / replaced navigation links on the page... Facebook doesn't allow custom styling.
I'm not sure if this is the fault of ColdFusion or just of MySpace programmers being incredibly shitty, but every 5-10 navigations on MySpace would usually result in a server error. Sometimes, you'd get a server error when the server tried to serve the error page! Facebook has had occasional stability issues, and PHP is lame (but then, apparently very little of their backend is still PHP), but it's rock-solid by comparison.
Back when MySpace was hemmorhaging users to Facebook, there was a limit on the number of pictures you could host on MySpace. Considering that one of the main uses of Facebook for some people seems to be "host every single picture my phone can take" you can see why this appeals.
Strange though it may be to think of Facebook and security together, they beat the pants off MySpace, which has such glamorous characteristics as being the first site to host an in-the-wild XSS worm (because it was trivial to inject script into your page, and somebody figured out how to exploit that).
When applied to a codec, "latency" (obviously) refers to stream latency, not network latency (the latter has nothing to do with a codec, obviously). The problem with codecs like MP3 for streaming purposes is that they encode fairly large "frames" of audio, and these frames must be recorded before they can be encoded, encoded before they can be transmitted, received before they can be decoded, and quite possibly also decoded (fully) before they can be played. It may be possible to begin playing before the decoding is complete, which would help a lot, but it also might not - it depends on the codec.
Suppose you've got a "high latency" codec (such as MP3) that uses a 250ms frame and requires full decoding (this is an example; I don't know the actual numbers for MP3). Then suppose you have a low-latency codec (like Opus) with a 15ms frame size. In both cases, your network latency is going to be the same (let's say 100ms). You want to stream audio over this connection. It's pretty high bandwidth and you've got a decent audio processor, so any codec can be encoded, transmitted, and decoded in 10ms or less.
At t=0, begin recording an audio (such as voice) segment.
Codec1 (high-latency): At t=250ms, you've filled the frame and can begin compression. At t=360ms, the frame has been encoded, transmitted, received, and decoded. Total latency before playback can begin: almost 3/8 of a second after recording began.
Codec2 (low-latency): At t=15ms, you've filled an audio frame and can begin compression. At t=125ms, the frame has been recieved and decoded by the other end, and playback can begin. Total latency: 1/8 of a second over the same network connection.
1/8 of a second can be perceived, but barely, and almost all of that is simply an inherent cost of the network transmission. 360ms is not only easy to perceive, it's quite enough to be annoying (think intercontinental call via satellite). There's tons of demand for low-latency codecs.
This is correct. MS changes the kernel major version number when they introduce major (sometimes backward-incompatible) driver-interface changes. They actually aren't always backward-incompatible; NT6.0 (Vista) would actually load most NT5.1 (XP) or even 5.0 (2000) drivers just fine... but it wasn't generally supported, and the installers would freak out at the changed major version number (this could be worked around by running in Compatibility Mode to spoof the version info, among other things). Besides, some drivers (notably network and printer drivers, which had significant interface changes) just *didn't* work correctly, if at all, with NT6.x. Windows 8 is still NT 6.2 because, although they've removed a few more of the old NT5.x driver interfaces, the 6.x drivers will still work.
Actually, the main reason for the whole "seat backs up, tray tables closed, put away your portable electronics" rule is that the takeoff and landing are the most dangerous parts of a flight, and if something goes wrong, people need to be able to respond, need to not be distracted, and need to not have extra impediments to moving within the cabin.
For in-flight, the ban on cellular phones is actually technical in reason: each cell tower can only handle so many connected devices at once, even if they're not actively communicating with the tower. Cell phones use line-of-sight frequencies, which means that on the ground, any given phone is only going to see (and consume "slots" on) a handful of towers. In the air, every phone that's turned on will blanket a huge number of towers. For one of two phones this doesn't matter at all (so yeah, turning on your phone in an emergency is fine), but if people didn't turn their phone radios off, every passenger in every plane over a given city would be adding to the load of every single tower.
Just out of curiosity, have you tried installing a generic copy of Windows on generic hardware? I have. It's not a pleasant experience.
Quite often, yes. On Win7 or Win8 now, or on Vista before Win7, it's quite painless (in Vista's case, I'm assuming a sufficiently powerful machine). Yeah, XP sucks at automatically pulling drivers from the Internet, and its included driver store is out of date. It's also 11 years old. To put that in perspective, it's older than most desktop-oriented Linux distros (three years on Ubuntu for example) and back when it shipped, most commodity hardware would require that you compile your own kernel drivers on Linux; at least on XP you could go pull the drivers off the manufacturer's website and burn them onto a CD or something (assuming the network ethernet driver didn't work, which the only time I experienced that in the last ten years was on Fedora 11).
Speak for yourself. I develop stuff on Linux, so I'm a developer and user. Much of what you suggest would make it an inferior system, or are plain wrong.
You are exactly not the target user of "Linux on the Desktop" in the sense that people mean in articles like this. A successful desktop OS not only does not require that its users be developers, it assumes that they aren't.
1) Full functionality out of the box. Did you know that neither Windows or OSX come with a compiler out of the box? Talk about lacking full functionality.
Why would a desktop user give a damn about a compiler? They're not a developer, so they aren't compiling their own code. If they have to compile somebody else's code, that's hardly full functionality out of the box. Here's what a Windows user thinks "full functionality" means: Can it open Word documents correctly and run my programs? They don't want to deal with LibreOffice screwing up the formatting. They don't know about Wine or want to deal with it. If an OS can't run Photoshop or World of Warcraft, it's hardly fully functional to them!
2) To apply tools toward other problems (not to apply their own labor toward tool maintenance/creation). Linux provides plenty of tools and is basically solid and maintainance free.
To a desktop OS user, "perl" and "fsck" aren't tools, they're misspelled jewelery and sex. To them, iTunes is a tool and TurboTax is a tool. As for maintentance, I've lost more Linux systems to botched updates that broke things beyond the point of it being woth repairing (2, and I've only been using Linux since 2006) than I've lost Windows systems to malware (1, and that was in the 90s; I was a kid). That's not counting situations where things like a video driver update and a kernel update at the same time produced a system that would no longer boot to a graphical encironment, because I (through lynx and other CLI tools) was able to recover from those. The typical desktop user wouldn't have a hope (though admittedly they'd probably get malware more often too). Those were official updates though, not the sort of thing you expect to break an OS.
4) Respect for what they're trying to accomplish. Quite. I only get this under Linux. Other operating systems have all sorts of stupid restrictions, that generally end up getting on my nerves in short order. Linux lets you do anything you like with it.
You have (once again) completely missed the point. Hypothetically, imagine I'm a Linux newbie and am chatting with you about something unrelated. You mention that you use Linux. I say "I just installed Linux and now I can't find the Internet." Do you: Tell me to run ifconfig and show you the output? Tell me to try pinging a server? Show me how to use the NetworkManager widget? Ask if the cable is connected? Tell me that on Linux, "the Internet" is called IceWeasel and show me the icon? Hint: the last one is most likely the solution. Now, imagine you didn't figure that out right away, and it only dawned on you that I was looking for Internet Explorer when I say that I need to get to Farmville or my crops will all die (or some such; I've never "played" it)? How much respect are you going to show a new Linux user trying to find Internet Explorer so they can reach Farmville? Because on average, that's how a substantial portion of desktop OS user time on the PC is spent.
Linux provides none of these, 20 years on. From the user's perspective, it is thus broken. That's crap. Of the things you've listed, Linux provides 4/4 while all other systems provide a grand total of 1/4.
To you, maybe. I say again, you are not the target user. Linux is already successful on the desktop among people like you. When or if desktop Linux ever reaches 4/4 (even 1/4 would be a big step forward) for the normal desktop OS user, it will be successful among then general populace. R
Tools (gear icon) -> Manage Add-ons -> select Shockwave Flash Object -> More Information (hyperlink text in the lower panel) -> Remove all sites. (These instructions are from IE9 but I believe it's the same on IE8; I just don't have a handy install of the latter).
This prevents Flashplayer from loading without you first granting it permission to do so. The grant is domain-wide, so it's less fine-grained than true Flashblock, but it does consider the source domain rather than the current page domain, so you can allow first-party Flash content while still blocking third-party ads.
You can actually turn the "InPrivate Filtering" (not to be confused with the completley unrelated "InPrivate Browsing" a.k.a. pr0n mode) into a half-decent ad blocker as well, since it will block third-party content and you can add all advertising domains to the blocklist, but that's somewhat more hassle.
Mango apps resume instantly (they're suspended in RAM, that's all). If Rovio hasn't gotten around to recompiling Angry Birds for Mango I'd be surprised (it's literally a three-click process in Visual Studio) but I suppose that's possible. In any case, most games resume instantly after you switch back from the call interface, even if you're still on the call (games will usually resume in a paused state for obvious reasons, but that's just a convenience fo rhte user).
WP8 will run all WP7 apps, which presumably means it will continue to support instant resume. The increased amount of RAM on some models may also allow suspending more apps, which would be nice.
Also, you can totally use C/C++ for WP7 development. There are even some (few) third-party apps in the Marketplace which do so. You just have to either figure out the tricks yourself (homebrew developers did this almost immediately) or get Microsoft approval (OEM apps and the officially-sanctioned Adobe Reader app being examples where that permission was granted beforehand).
On a serious note, though, you actually can run POSIX apps on Server 2012. NT has, since its inception, included support for POSIX APIs and filesystem behavior. These days it's called SUA (Subsystem for UNIX Applications) and a smallish but fully functional operating environment for it, called Interix, is available for free. The installer will also let you enable various tweaks such as SetUID/SetGID behavior and filesystem case sensitivity, things you can't get with Cygwin or the like. It's implemented as an NT subsystem, same as Win32, so the speed is basically native as well. Interix comes with a working build toolchain, plus you can get a package manager for a repository of precompiled software and updates from http://suacommunity.com./
I'm not sure I'd advocate adopting it at this point if you haven't already - MS has been making moves toward discontinuing support for some years now, and it appears to no longer be in any of the client editions but Enterprise - but it exists, and it works. MS themselves used it to host Hotmail on Apache before they ported it to run on IIS. I use it (on client) both for various utilities that I prefer the POSIX versions of (git and ssh and such, plus sometimes there is no Win32 version) and for bash (my primary shell).
No, I don't know how many times Apache got caught for such stupidity. Care to share some references?
There's a huge difference between "ship with no known bugs" and "ship with no externally known security exploits". The former is unrealistic of any major piece of software. The latter is (or should be) mandatory of any major software vendor. The folks who reported the 19 vulns originally also sent Oracle 12 distinct POCs for those vulnerabilities. To date (over four months later), Oracle has patched only 6 of those vulnerabilities, and broken at least two of the POCs... but that still leaves an awfully large number of them unaddressed, and it's not as if they haven't had time to address them.
Oracle, and unfortunately by extension Java, is shit. Even Microsoft isn't nearly so bad.
JPEG fuzzing is relatively easy, so the popular parsers of the format have become quite safe over time. As a general class of exploit, though, such things definitely still exist. They're nothing like the Java vulns under discussion here, except for the insignificant similarity that they can be used for remote attacks though a browser, but similar attacks targeting various complex binary formats (*cough*PDF*cough*) are still being developed.
Java spplets aren't a browser vulnerability, they're a Java vulnerability. The entry vector is through the browser, but that's beside the point - Java is supposed to provide a sandbox for applets and that sandbox's walls are awfully low. The problem isn't that the attacker can tell Java to execute arbitrary code, it's that Java will obey even when that code violates the security guarantees it is supposedly making.
Also, you should brush up on your computing history. Java applets are explicitly designed as a feature of the language and the runtime (including, in theory, the applet sandbox). They're nothing like ActiveX in that regard, which is simply compiled code (COM objects, more precisely) that IE (and a handful of other apps) will allow you to load into the browsing session (or document, or whatever). In the days before JavaScript could be used for anything powerful, and Flash was only for animations with almost no interactive capability, Java applets were how you did rich content on the web. There was a time when applets were viewed as *the* reason to learn Java, and the platform was marketed on the power of applets.
Correct, but slightly missing the point I was trying to make. The Java vulns being discussed here are all ways to break out of the applet sandbox. Java applets *are* Java - they're exactly the same language, executing in exactly the same runtime - but there's supposed to be restrictions on the APIs that allow Java code to modify the system it runs on. These restrictions form the applet sandbox, and breaking them allows a website to gain arbitrary code execution on your system.
The important point that I was trying to make is that, unlike your typical browser bug or image rendering bug, these Java exploits are platform agnostic. A malformed JPEG may successfully execute shellcode on one broken image decoder/renderer, simply crash another, and be caught and thrown out by a third. Which thing happens to any given client (visitor to the page hosting it) will depend on the client's software environment: their browser, their OS, whether they use 32-bit or 64-bit, etc. If you want to make it cross-platform, you'll need to not only have an exploit that works on multiple image libraries (or a suite of exploits that together cover all libraries, and some way to tell which one to use), you'll need shellcode that executes on all those platforms (and shellcoding is hard, especially in the face of the exploit mitigations found in most modern OSes).
A Java applet sandbox-break like these exploits is almsot totally platform-agnostic. It may care what JRE you're using, but pretty much everybody uses the official one from Oracle. Even if you don't though, if your third-party JRE allows applets to access the same APIs as the official one, you're screwed too. Implementation differences between the JREs are unlikely to save you; the exploits are legitimate Java code calling official APIs that just really shouldn't be callable from an applet. Exploit mitigations are of no use at all; once out of the sandbox, the Java code can run any payload it wants, still entirely within the proper behavior of the JRE. True, the payloads will be platform specific (due to differences in filesystem layout, names and locations of installed software, and so on, plus obviously if you want to download a native payload it will need to have been compiled for the target platform) but compared to writing even a single working shellcode, writing a payload for every single major OS platform out there (or more likely, simply using your favorite one from Metasploit or similar) is trivial.
The tricky part of writing a Java applet exploit is just figuring out the sequence of function calls to break out of the sandbox. Once you've done that, everything else is trivial; it's just Java code like any other. This is a flaw in the Java applet feature more than in the language itself, but that doesn't remove the fact that the language's write-once-run-everywhere nature significantly increases the impact of security vulns and correspondingly requires much greater vigilance on the part of the developer.
Normally I'd agree with you, but the exact same thing is true of JavaScript and yet very, very few people are calling for a universal end to that. Now, a handful of people (relative to the global computer userbase) use NoScript, but even among NoScript users most realize that it's either too complex or too difficult for most people to use correctly all the time.
As it happens, I do block plug-ins (especially Flash and Java) by default, permitting them only on a case-by-case basis, except where I can remove them entirely. However, even to my (highly technical; he's been coding since he was in high school) father, that's too much of a hassle. He expects (rightly, if not wisely) that software vendors will keep their software as secure as possible, and respond quickly to any threats. That's the standard to which I'm holding Oracle here, and they're failing to meet it.
Ah, but ActiveX only ever ran on Microsoft platforms. With Java, you can exploit OS X, Linux, BSD, and so on through any browser with the Netscape plugin API (a.k.a. almost all of them)! Truly, a great day for the blackhats of the world.
On a more serious note, this does highlight two problems with modern computing: 1. Write-once-run-everywhere is convenient for developers, but puts a huge security purden on the platform developer (a burden which Oracle seems either unwilling or unable to bear). If you want to become the universal execution platform, you better make damn sure you aren't allowing universal exploitation too. 2. Yes, Macs and Linux users and anybody else who can load a Java applet in their browser is vunlerable to malware, even 0-day (well, 0-day for patches, more like 120-day since the vendor was notified) exploits. If nobody bothers to attack your system, it's simply because the value they can get from it isn't worth the cost of developing the payload (which is hardly difficult). If you want to be a success in the market, though, you're going to have to take the scrutiny that comes along with it. Don't be complacent; you're far from immune.
Slashdot Mirror
Oh, let's see.
Proper anonymous functions, including lambdas.
Proper function pointers (called delegates) without needing to write entire classes for them.
Support for stack-allocated complex types (structs).
Support for bi-directional and output parameters, even of types normally passed by value.
Unsigned integer types.
Object parameters (technically functions, but cleaner than a bunch of Get*and Set* function definitions and usages).
Proper generics (try declaring an array of generic type in Java, for example).
Easy interop with native code (P/Invoke, good marshaling capabilities, support for ordered structs and unsigned types, etc.).
Support for direct memory access (if you want/need it; use the unsafe keyword and byte* or similar types).
LINQ.
Tuples.
No one-public-class-per-source-file restriction, or the associated restriction on file name.
No restriction on project directory structure.
Partial classes (allows separating parts of the same class, such as autogenerated code from developer code, into different files).
The using keyword (in both of its uses).
Conditional compilation (similar to C preprocessor) to do things like exclude debug code without any overhead at all.
These are the ones that came to mind in just a few minutes of thinking about it, based on personal experiences, I'm sure there's a ton more. C# is a vastly more advanced language than Java. I don't deny that MS learned heavily from Java, but half of that learning was "let's not repeat their mistakes" and the other half was "what is it really lame that this language lacks? Let's do better."
How exactly do you propose that Google kick Amazon out of the Open Handset Allienace when Amazon is not, never has been, and is not trying to be a member of the OHA? Your post is ludicrous.
Amazon has been doing this from the beginning; using the Android codebase as a starting point and releasing a product using their derived version of Android, without any Google support or any of the otehr advantages that OHA members get. They're doing fine, too... but they aren't making a smartphone.
I don't personally support the current patent system, but the answer to your question is blindingly obvious: because if you can't put restrictions on the use of the algorithm, your competitors are going to come along, and use it themselves without either incurring the R&D cost or compensating your for it. Thus they're able to offer competing products at a lower cost, making computer science R&D a counter-productive strategy to running a competitive business (i.e. stifling innovation). Patents are supposed to be the solution to this problem.
Practically speaking, the current system is just broken. The basis of it is important, but the way it's being used is extremely harmful.
Windows Mobile bears absolutely no resemblence to Windows Phone, especially not to WP8, and that includes the design decisions. I get what you're saying about them continually trying for a unified interface, though.
WTF do you mean, Surface was never released? I've seen at least four of them in the wild. They cost a crapload, so they weren't as popular as they might have been, but they definitely exist.
Also, they gave all employess WP7 devices too; the addition fo the Surface is new this time around but the idea of "new product; everybody gets one!" isn't even new within phones for MS.
60' is "a boat that small" to you? People routinely cruise the world on monohulls that are 40' or less. I'm guessing you have either very little, or very strange, blue-water experience.
That said, there are a few things to keep in mind. You want a *lot* of redundency in some systems, like GPS and radio. Get at least two handheld VHF radios. Get at least two mounted GPS receivers, plus a handheld (two if you make a ditch bag, and on a monohull you should; put an extra VHF in here too of course) and probably at least one for your PC (USB interface). If you have a smartphone, that's one more (which is good), not a replacement for one of the others. Carry a ton of spare batteries.
A watermaker is a huge improvement to the cruising experience. As long as it keeps working, you don't have to go on severe water rationing during ocean passages and you can avoid the hassle of tying up to take on water all the time. DC-driven ones are best if you're going with solar panels and/or a wind turbine, but if you're going to have a generator, hook the watermaker up to that (ideally directly, although via AC wiring works too).
Energy independence, usually via photovoltaics and/or wind, is a marvelous thing. Consider making an energy budget (there are charge controlers that will monitor battery state and flow in both directions for you; these help a lot). Make sure you charge a "house" battery separately from the engine battery; it's great to have the ability to connect them, but don't do it by default.
Make sure there's a way to get water out of the tanks (for example, a foot or hand pump) in case of a power (or powered pump) failure.
A good quad-band SIM-unlocked 3G modem is a wonderful thing. Most parts of the world now offer cellular Internet service, often good enough for Skype. A smartphone may also work, if it's got an easy way to tether.
Lots of other advice, but it's late and I'm tired. Go check out http://svocelot.com/ for a lot more info; my family has been cruising for over ten years on the current boat, and did so for seven years back in the 80s as well.
Personal history (3.5 years of blue-water cruising, 12K+ sea miles) suggests you're safer without one anyhow. The people we heard of getting shot were either the ones who pulled a gun on their boarders, or who had a guun on board when the boarders snuck on at night (the boarders found the gun, shot the owner, and left).
"Pirates" in the usual sense aren't really the problem. The much bigger problem is people sneaking onto your boat while you're either away or asleep, and stealing things. They aren't always armed, but if they are, going for your own gun probably won't help, and if they aren't, they may find your gun before you can get to it.
Incidentally, dinghies are the first to go; use a steel cable or chain and haul the dingy out of the water at night. Make sure the outboard is *very* well secured, as well; a strong and high-quality stainless steel padlock works well, but remember that a hacksaw can get through that too. Unlike pirates, which can generally be avoided just by having some caution rgarding what parts of the world you sail, boarders are more-or-less a risk everywhere; consider investing in a simple motion sensor alarm for the rougher areas.
Oh, for anybody who is curious, my family's website: http://svocelot.com/ . Check out the section devoted to the boat gear in particular (for relevance to this Ask Slashdot).
If you're actually going blue-water cruising, go with PACTOR (v3 or better). The speed jump will matter a *LOT* (for things like pulling down GRIB files with decent area and detail, you'll want all the bandwidth you can get). Downloading 50K or more is reasonable with PACTOR3 (what we used when I was cruising); try that over WINMOR and you'll probably be kicked off the ground station or lose propagation first.
Sailmail is all right, and certainly better than nothing. For most purposes, Winlink 2000 is better; the ground stations are less crowded and you can connect for longer periods of time, plus most of them support faster PACTOR connections. You do need a HAM licence high enough to use the HF bands (so, General class), and of course a compatible radio and modem (get something capable of PACTOR3, unless they've introduced a newer, better variant). You also can't legally use HAM radio (and thus, can't use Winlink) to discuss business, so if you expect to need that, Sailmail might be better. For most cruisers that's no problem, though.
I'm not going to recommend radio gear - the boat I lived on uses an Icom 706mk2g, which is a great little 100W radio aside from needing an external tuner, but that was some 11 years ago. Antennas bear thinking about though. Random wire actually works fine, so long as you get it high enough, have a good enough antenna tuner, and a good enough ground. Dipoles work better, but only for specific bands; you'll want to think carefully about that. Directional antennas are generally poinless on a sailboat; even if you can mount one, you can't keep it pointed the right way.
Also, consider the radio environment. Any RF sources on the boat, such as alternators (engine, generator, windcharger, etc.) or DC-DC voltage-converters (such as for solar panels or a laptop charger) are going to play havoc with your reception for either voice or data. You can get RF-insulated DC voltage converters suitable for use with a laptop online, though. You'll also need a good set of ferrite chokes; most consumer electronics either have insufficient chokes or none at all. This will result in those electronics going crazy (mouse dancing all over the screen and clicking random things, for example) if you key a powerful HF radio nearby.
Where the fuck did this " 52' " thing come from? I mean, I'm used to Americans not knowing how to use Metric, but I expected at least basic competency in math. A meter is *more* than three feet. Thus, 18m > 54' i.e. longer than 52' (it's actually close enough to 60' for rounding error).
iOS6 is supported all the way back to the iPhone 3GS. How is this creating any fragmentation?
Except, that's not really true. Some features of iOS 4, 5, and 6 were backported to the old hardware, and the version number was incremented, but a number of the defining features aren't present at all, or are crippled.
Siri is an obvious example; it's a software feature (there's some hardware in the newer iPhones that improves the experience, but the feature itself is pure software) that doesn't even put much strain on the local capabilities of the device, yet it's not available for the 3GS.
Then there's app fragmentation. Apps written for the "retina" resolution aren't going to work on a 3GS. Apps written for the new 16:9 resolution aren't even going to work on a 4S. Android designed around this problem from the beginning (although it was an issue with Windows Mobile, before that OS was EoLed).
iOS is less fragmented than Android, sure. But it's definitely still fragmented, and new releases that change things like aspect ratio aren't going to help.
You badly, badly misremember the awfulness of MySpace. Please don't make me post this more than once, the memories are painful...
Embedded Flash objects in the page. Lots of them. All set to auto-play when the page loads. Facebook doesn't allow embedding arbitrary content, and doesn't allow auto-playing video on your page either.
Incredibly atrocious CSS, like text that ballooned to 40pt on hover or that was in incredibly unreadable fonts, or covered up / replaced navigation links on the page... Facebook doesn't allow custom styling.
I'm not sure if this is the fault of ColdFusion or just of MySpace programmers being incredibly shitty, but every 5-10 navigations on MySpace would usually result in a server error. Sometimes, you'd get a server error when the server tried to serve the error page! Facebook has had occasional stability issues, and PHP is lame (but then, apparently very little of their backend is still PHP), but it's rock-solid by comparison.
Back when MySpace was hemmorhaging users to Facebook, there was a limit on the number of pictures you could host on MySpace. Considering that one of the main uses of Facebook for some people seems to be "host every single picture my phone can take" you can see why this appeals.
Strange though it may be to think of Facebook and security together, they beat the pants off MySpace, which has such glamorous characteristics as being the first site to host an in-the-wild XSS worm (because it was trivial to inject script into your page, and somebody figured out how to exploit that).
When applied to a codec, "latency" (obviously) refers to stream latency, not network latency (the latter has nothing to do with a codec, obviously). The problem with codecs like MP3 for streaming purposes is that they encode fairly large "frames" of audio, and these frames must be recorded before they can be encoded, encoded before they can be transmitted, received before they can be decoded, and quite possibly also decoded (fully) before they can be played. It may be possible to begin playing before the decoding is complete, which would help a lot, but it also might not - it depends on the codec.
Suppose you've got a "high latency" codec (such as MP3) that uses a 250ms frame and requires full decoding (this is an example; I don't know the actual numbers for MP3). Then suppose you have a low-latency codec (like Opus) with a 15ms frame size. In both cases, your network latency is going to be the same (let's say 100ms). You want to stream audio over this connection. It's pretty high bandwidth and you've got a decent audio processor, so any codec can be encoded, transmitted, and decoded in 10ms or less.
At t=0, begin recording an audio (such as voice) segment.
Codec1 (high-latency):
At t=250ms, you've filled the frame and can begin compression.
At t=360ms, the frame has been encoded, transmitted, received, and decoded.
Total latency before playback can begin: almost 3/8 of a second after recording began.
Codec2 (low-latency):
At t=15ms, you've filled an audio frame and can begin compression.
At t=125ms, the frame has been recieved and decoded by the other end, and playback can begin.
Total latency: 1/8 of a second over the same network connection.
1/8 of a second can be perceived, but barely, and almost all of that is simply an inherent cost of the network transmission. 360ms is not only easy to perceive, it's quite enough to be annoying (think intercontinental call via satellite). There's tons of demand for low-latency codecs.
This is correct. MS changes the kernel major version number when they introduce major (sometimes backward-incompatible) driver-interface changes. They actually aren't always backward-incompatible; NT6.0 (Vista) would actually load most NT5.1 (XP) or even 5.0 (2000) drivers just fine... but it wasn't generally supported, and the installers would freak out at the changed major version number (this could be worked around by running in Compatibility Mode to spoof the version info, among other things). Besides, some drivers (notably network and printer drivers, which had significant interface changes) just *didn't* work correctly, if at all, with NT6.x. Windows 8 is still NT 6.2 because, although they've removed a few more of the old NT5.x driver interfaces, the 6.x drivers will still work.
Actually, the main reason for the whole "seat backs up, tray tables closed, put away your portable electronics" rule is that the takeoff and landing are the most dangerous parts of a flight, and if something goes wrong, people need to be able to respond, need to not be distracted, and need to not have extra impediments to moving within the cabin.
For in-flight, the ban on cellular phones is actually technical in reason: each cell tower can only handle so many connected devices at once, even if they're not actively communicating with the tower. Cell phones use line-of-sight frequencies, which means that on the ground, any given phone is only going to see (and consume "slots" on) a handful of towers. In the air, every phone that's turned on will blanket a huge number of towers. For one of two phones this doesn't matter at all (so yeah, turning on your phone in an emergency is fine), but if people didn't turn their phone radios off, every passenger in every plane over a given city would be adding to the load of every single tower.
Just out of curiosity, have you tried installing a generic copy of Windows on generic hardware? I have. It's not a pleasant experience.
Quite often, yes. On Win7 or Win8 now, or on Vista before Win7, it's quite painless (in Vista's case, I'm assuming a sufficiently powerful machine). Yeah, XP sucks at automatically pulling drivers from the Internet, and its included driver store is out of date. It's also 11 years old. To put that in perspective, it's older than most desktop-oriented Linux distros (three years on Ubuntu for example) and back when it shipped, most commodity hardware would require that you compile your own kernel drivers on Linux; at least on XP you could go pull the drivers off the manufacturer's website and burn them onto a CD or something (assuming the network ethernet driver didn't work, which the only time I experienced that in the last ten years was on Fedora 11).
Speak for yourself. I develop stuff on Linux, so I'm a developer and user. Much of what you suggest would make it an inferior system, or are plain wrong.
You are exactly not the target user of "Linux on the Desktop" in the sense that people mean in articles like this. A successful desktop OS not only does not require that its users be developers, it assumes that they aren't.
1) Full functionality out of the box.
Did you know that neither Windows or OSX come with a compiler out of the box? Talk about lacking full functionality.
Why would a desktop user give a damn about a compiler? They're not a developer, so they aren't compiling their own code. If they have to compile somebody else's code, that's hardly full functionality out of the box. Here's what a Windows user thinks "full functionality" means: Can it open Word documents correctly and run my programs? They don't want to deal with LibreOffice screwing up the formatting. They don't know about Wine or want to deal with it. If an OS can't run Photoshop or World of Warcraft, it's hardly fully functional to them!
2) To apply tools toward other problems (not to apply their own labor toward tool maintenance/creation).
Linux provides plenty of tools and is basically solid and maintainance free.
To a desktop OS user, "perl" and "fsck" aren't tools, they're misspelled jewelery and sex. To them, iTunes is a tool and TurboTax is a tool. As for maintentance, I've lost more Linux systems to botched updates that broke things beyond the point of it being woth repairing (2, and I've only been using Linux since 2006) than I've lost Windows systems to malware (1, and that was in the 90s; I was a kid). That's not counting situations where things like a video driver update and a kernel update at the same time produced a system that would no longer boot to a graphical encironment, because I (through lynx and other CLI tools) was able to recover from those. The typical desktop user wouldn't have a hope (though admittedly they'd probably get malware more often too). Those were official updates though, not the sort of thing you expect to break an OS.
4) Respect for what they're trying to accomplish.
Quite. I only get this under Linux. Other operating systems have all sorts of stupid restrictions, that generally end up getting on my nerves in short order. Linux lets you do anything you like with it.
You have (once again) completely missed the point. Hypothetically, imagine I'm a Linux newbie and am chatting with you about something unrelated. You mention that you use Linux. I say "I just installed Linux and now I can't find the Internet." Do you: Tell me to run ifconfig and show you the output? Tell me to try pinging a server? Show me how to use the NetworkManager widget? Ask if the cable is connected? Tell me that on Linux, "the Internet" is called IceWeasel and show me the icon? Hint: the last one is most likely the solution. Now, imagine you didn't figure that out right away, and it only dawned on you that I was looking for Internet Explorer when I say that I need to get to Farmville or my crops will all die (or some such; I've never "played" it)? How much respect are you going to show a new Linux user trying to find Internet Explorer so they can reach Farmville? Because on average, that's how a substantial portion of desktop OS user time on the PC is spent.
Linux provides none of these, 20 years on. From the user's perspective, it is thus broken.
That's crap. Of the things you've listed, Linux provides 4/4 while all other systems provide a grand total of 1/4.
To you, maybe. I say again, you are not the target user. Linux is already successful on the desktop among people like you. When or if desktop Linux ever reaches 4/4 (even 1/4 would be a big step forward) for the normal desktop OS user, it will be successful among then general populace. R
IE has what amounts to a built-in Flashblock.
Tools (gear icon) -> Manage Add-ons -> select Shockwave Flash Object -> More Information (hyperlink text in the lower panel) -> Remove all sites. (These instructions are from IE9 but I believe it's the same on IE8; I just don't have a handy install of the latter).
This prevents Flashplayer from loading without you first granting it permission to do so. The grant is domain-wide, so it's less fine-grained than true Flashblock, but it does consider the source domain rather than the current page domain, so you can allow first-party Flash content while still blocking third-party ads.
You can actually turn the "InPrivate Filtering" (not to be confused with the completley unrelated "InPrivate Browsing" a.k.a. pr0n mode) into a half-decent ad blocker as well, since it will block third-party content and you can add all advertising domains to the blocklist, but that's somewhat more hassle.
Mango apps resume instantly (they're suspended in RAM, that's all). If Rovio hasn't gotten around to recompiling Angry Birds for Mango I'd be surprised (it's literally a three-click process in Visual Studio) but I suppose that's possible. In any case, most games resume instantly after you switch back from the call interface, even if you're still on the call (games will usually resume in a paused state for obvious reasons, but that's just a convenience fo rhte user).
WP8 will run all WP7 apps, which presumably means it will continue to support instant resume. The increased amount of RAM on some models may also allow suspending more apps, which would be nice.
Also, you can totally use C/C++ for WP7 development. There are even some (few) third-party apps in the Marketplace which do so. You just have to either figure out the tricks yourself (homebrew developers did this almost immediately) or get Microsoft approval (OEM apps and the officially-sanctioned Adobe Reader app being examples where that permission was granted beforehand).
Haha.
On a serious note, though, you actually can run POSIX apps on Server 2012. NT has, since its inception, included support for POSIX APIs and filesystem behavior. These days it's called SUA (Subsystem for UNIX Applications) and a smallish but fully functional operating environment for it, called Interix, is available for free. The installer will also let you enable various tweaks such as SetUID/SetGID behavior and filesystem case sensitivity, things you can't get with Cygwin or the like. It's implemented as an NT subsystem, same as Win32, so the speed is basically native as well. Interix comes with a working build toolchain, plus you can get a package manager for a repository of precompiled software and updates from http://suacommunity.com./
I'm not sure I'd advocate adopting it at this point if you haven't already - MS has been making moves toward discontinuing support for some years now, and it appears to no longer be in any of the client editions but Enterprise - but it exists, and it works. MS themselves used it to host Hotmail on Apache before they ported it to run on IIS. I use it (on client) both for various utilities that I prefer the POSIX versions of (git and ssh and such, plus sometimes there is no Win32 version) and for bash (my primary shell).
No, I don't know how many times Apache got caught for such stupidity. Care to share some references?
There's a huge difference between "ship with no known bugs" and "ship with no externally known security exploits". The former is unrealistic of any major piece of software. The latter is (or should be) mandatory of any major software vendor. The folks who reported the 19 vulns originally also sent Oracle 12 distinct POCs for those vulnerabilities. To date (over four months later), Oracle has patched only 6 of those vulnerabilities, and broken at least two of the POCs... but that still leaves an awfully large number of them unaddressed, and it's not as if they haven't had time to address them.
Oracle, and unfortunately by extension Java, is shit. Even Microsoft isn't nearly so bad.
JPEG fuzzing is relatively easy, so the popular parsers of the format have become quite safe over time. As a general class of exploit, though, such things definitely still exist. They're nothing like the Java vulns under discussion here, except for the insignificant similarity that they can be used for remote attacks though a browser, but similar attacks targeting various complex binary formats (*cough*PDF*cough*) are still being developed.
Java spplets aren't a browser vulnerability, they're a Java vulnerability. The entry vector is through the browser, but that's beside the point - Java is supposed to provide a sandbox for applets and that sandbox's walls are awfully low. The problem isn't that the attacker can tell Java to execute arbitrary code, it's that Java will obey even when that code violates the security guarantees it is supposedly making.
Also, you should brush up on your computing history. Java applets are explicitly designed as a feature of the language and the runtime (including, in theory, the applet sandbox). They're nothing like ActiveX in that regard, which is simply compiled code (COM objects, more precisely) that IE (and a handful of other apps) will allow you to load into the browsing session (or document, or whatever). In the days before JavaScript could be used for anything powerful, and Flash was only for animations with almost no interactive capability, Java applets were how you did rich content on the web. There was a time when applets were viewed as *the* reason to learn Java, and the platform was marketed on the power of applets.
Correct, but slightly missing the point I was trying to make. The Java vulns being discussed here are all ways to break out of the applet sandbox. Java applets *are* Java - they're exactly the same language, executing in exactly the same runtime - but there's supposed to be restrictions on the APIs that allow Java code to modify the system it runs on. These restrictions form the applet sandbox, and breaking them allows a website to gain arbitrary code execution on your system.
The important point that I was trying to make is that, unlike your typical browser bug or image rendering bug, these Java exploits are platform agnostic. A malformed JPEG may successfully execute shellcode on one broken image decoder/renderer, simply crash another, and be caught and thrown out by a third. Which thing happens to any given client (visitor to the page hosting it) will depend on the client's software environment: their browser, their OS, whether they use 32-bit or 64-bit, etc. If you want to make it cross-platform, you'll need to not only have an exploit that works on multiple image libraries (or a suite of exploits that together cover all libraries, and some way to tell which one to use), you'll need shellcode that executes on all those platforms (and shellcoding is hard, especially in the face of the exploit mitigations found in most modern OSes).
A Java applet sandbox-break like these exploits is almsot totally platform-agnostic. It may care what JRE you're using, but pretty much everybody uses the official one from Oracle. Even if you don't though, if your third-party JRE allows applets to access the same APIs as the official one, you're screwed too. Implementation differences between the JREs are unlikely to save you; the exploits are legitimate Java code calling official APIs that just really shouldn't be callable from an applet. Exploit mitigations are of no use at all; once out of the sandbox, the Java code can run any payload it wants, still entirely within the proper behavior of the JRE. True, the payloads will be platform specific (due to differences in filesystem layout, names and locations of installed software, and so on, plus obviously if you want to download a native payload it will need to have been compiled for the target platform) but compared to writing even a single working shellcode, writing a payload for every single major OS platform out there (or more likely, simply using your favorite one from Metasploit or similar) is trivial.
The tricky part of writing a Java applet exploit is just figuring out the sequence of function calls to break out of the sandbox. Once you've done that, everything else is trivial; it's just Java code like any other. This is a flaw in the Java applet feature more than in the language itself, but that doesn't remove the fact that the language's write-once-run-everywhere nature significantly increases the impact of security vulns and correspondingly requires much greater vigilance on the part of the developer.
Normally I'd agree with you, but the exact same thing is true of JavaScript and yet very, very few people are calling for a universal end to that. Now, a handful of people (relative to the global computer userbase) use NoScript, but even among NoScript users most realize that it's either too complex or too difficult for most people to use correctly all the time.
As it happens, I do block plug-ins (especially Flash and Java) by default, permitting them only on a case-by-case basis, except where I can remove them entirely. However, even to my (highly technical; he's been coding since he was in high school) father, that's too much of a hassle. He expects (rightly, if not wisely) that software vendors will keep their software as secure as possible, and respond quickly to any threats. That's the standard to which I'm holding Oracle here, and they're failing to meet it.
Ah, but ActiveX only ever ran on Microsoft platforms. With Java, you can exploit OS X, Linux, BSD, and so on through any browser with the Netscape plugin API (a.k.a. almost all of them)! Truly, a great day for the blackhats of the world.
On a more serious note, this does highlight two problems with modern computing:
1. Write-once-run-everywhere is convenient for developers, but puts a huge security purden on the platform developer (a burden which Oracle seems either unwilling or unable to bear). If you want to become the universal execution platform, you better make damn sure you aren't allowing universal exploitation too.
2. Yes, Macs and Linux users and anybody else who can load a Java applet in their browser is vunlerable to malware, even 0-day (well, 0-day for patches, more like 120-day since the vendor was notified) exploits. If nobody bothers to attack your system, it's simply because the value they can get from it isn't worth the cost of developing the payload (which is hardly difficult). If you want to be a success in the market, though, you're going to have to take the scrutiny that comes along with it. Don't be complacent; you're far from immune.