Slashdot videos: Now with more Slashdot!
Who says the OS should provide nothing useful and let app makers make their money on it?
If you set up a straw man, then it's very easy to kill it. The issue is not an OS providing something, it's that Microsoft, which had a near-monopoly in the desktop space, used the money from selling the OS to fund development in another market (browsers) and then bundled their version, undercutting the competition with cross subsidies. There was a thriving browser market before IE was introduced, but it's hard to compete when most of your customers are forced to pay to fund the development of your competitor.
Generally Fundamental Evangelical Christians teach humility and service to others and subscribe to the view that others are more important than me. That's exactly opposite to what you claim "ALL" religion is.
Really? Because that's exactly the set of values that I'd choose to indoctrinate my serfs with.
"You know that those who are recognized as rulers of the Gentiles lord it over them; and their great men exercise authority over them. But it is not this way among you, but whoever wishes to become great among you shall be your servant; "For even the Son of Man did not come to be served, but to serve, and to give His life a ransom for many."
Or, to summaries: 'Hey oppressed people, don't think about following a leader from amongst yourself, that kind of thing always ends badly'.
This obviously raises the question of why, when you have a serial console with working flow control, do you need laplink at all? If you have a null modem cable and a lot of patience, then you can always extract files by writing them to standard output and reading them off with a serial program - just make sure that you've correctly configured the UART first. If you're a bit paranoid, then running something like par2 first (I think there are DOS binaries and they're pretty small, though they may take a while on a 386) and you'll be able to recover small data errors.
Copying 160MB over a serial connection won't be fast, but I'm assuming that this isn't urgent if it's been sitting on a 160MB disk for years without backups...
IE itself can EASILY be removed from a system. Delete the EXE, done. Its been that way ALWAYS. Even during the court battles.
While this is technically true, it's also misleading. You could delete iexplore.exe, but don't expect a working system afterwards. Lots of other parts of Windows (and Office) invoked iexplore.exe directly, rather than providing a web view with MSHTML.dll or invoking the default browser via the URL opening APIs.
- MSHTML.dll (around which IE was a very thin wrapper) was installed by default and used by loads of things.
- Lots of things in Windows that should have used MSHTML.dll to embed a web view, or just invoked the default browser, used IE so that you couldn't uninstall IE without breaking Windows.
- MS bundled IE with Windows and used their near monopoly in the desktop OS market to gain a dominant position in the browser market and push Netscape (and a few other browser makers) out of business.
It was never part of the kernel and never ran with system-level privileges.
I saw a recent review of a smartphone that had two screens, one LCD and one eInk. The modern eInk display is able to get a high enough refresh for interactive use and doesn't drain the battery when done. The screen that I'd love to see is eInk with a transparent OLED on top, so that text can be rendered with the eInk display and graphics / video overlaid on the OLED. The biggest problem with eInk is that the PPI is not high enough to make them colour yet. You get 1/3 (or 1/4 if you want a dedicated black) of the resolution when you make the colour and so that means you're going to need at least 600PPI to make them plausible.
The other problem that they've had is that LCDs have ramped up the resolution. My first eBook reader had a 166PPI eInk display. Now LCDs are over 300PPI but the Kindle Paperwhite is only 212PPI, so text looks crisper on the LCD than the eInk display, meaning that you're trading different annoyances rather than having the eInk be obviously superior. With real paper you get (at least, typically a lot more than) 300DPI and no backlight.
Your neurones also become very complex, as they need to all be network nodes with store and forward and they are going to have to handle multiple inputs every cycle (consider a node in the middle. In the first cycle it can be signalled by 8 others, in the next it can be signalled by 12 and so on. The exact number depends on how you wire the network, but for a flexible implementation you need to allow this.
What's the justification for compilation unit boundary? It seems like you could expose the layout of the struct (and therefore any compiler shenanigans) through other means within a compilation unit. offsetof comes to mind.
That's the granularity at which you can do escape analysis accurately. One thing that my student explored was using different representations for the internal and public versions of the structure. Unless the pointer is marked volatile or any atomic operations occur that establish happens-before relationships that affect the pointer (you have to assume functions that you can't see the body of contain operations), C allows you to do a deep copy, work on the copy, and then copy the result back. He tried this to transform between column-major and row-major order for some image processing workloads. He got a speedup for the computation step, but the cost of the copying outweighed it (a programmable virtualised DMA controller might change this).
I suppose you could do that in C++ with template specialization. In fact, doesn't that happen today in C++11 and later, with movable types vs. copyable types in certain containers? Otherwise you couldn't have vector >. Granted, that specialization is based on a very specific trait, and without it the particular combination wouldn't even work.
The problem with C++ is that these decisions are made early. The fields of a collection are all visible (so that you can allocate it on the stack) and the algorithms are as well (so that you can inline them). These have nice properties for micro optimisation, but they mean that you miss macro optimisation opportunities.
To give a simple example, libstdc++ and libc++ use very different representations for std::string. The implementation in libstdc++ uses reference counting and lazy copying for the data. This made a lot of sense when most code was single threaded and caches were very small but now is far from optimal. The libc++ implementation (and possibly the new libstdc++ one - they're breaking the ABI at the moment) uses the short-string optimisation, where small strings are embedded in the object (so fit in a single cache line) and doesn't bother with the CoW trick (which costs cache coherency bus traffic and doesn't buy much saving anymore, especially now people use std::move or std::shared_ptr for the places where the optimisation would matter).
In Objective-C (and other late-bound languages) this optimisation can be done at run time. For example, if you use NSRegularExpression with GNUstep, it uses ICU to implement it. ICU has a UText object that implements an abstract text thing and has a callback to fill a buffer with a row of characters. We have a custom NSString subclass and a custom UText callback which do the bridging. The abstract NSString class has a method for getting a range of characters. The default implementation gets them one at a time, but most subclasses can get a run at once. The version that wraps UText does this by invoking the callback to fill the UText buffer and then copying. The version that wraps in the other direction just uses this method to fill the UText buffer. This ends up being a lot more efficient than if we'd had to copy between two entirely different implementations of a string.
In general though, there are some constructs that it is easy for a JVM to map efficiently to modern hardware and some that are hard. For example, pointer chasing in data is inefficient in any language and there's little that the JVM can do about it (if you're lucky, it might be able to insert prefetching hints after a lot of profiling). Cache coherency can still cause false sharing, so you want to make sure that fields of your classes that are accessed in different threads are far apart and ones accessed together want to be close - a JVM will sometimes do this for you (I had a student work on this, but I don't know if any commercial JVM does it).