Open Up Government to its Citizens: The Bush Administration has been one of the most secretive, closed administrations in American history.... Obama will integrate citizens into the actual business of government by:
Making government data available online in universally accessible formats to allow citizens to make use of that data to comment, derive value, and take action in their own communities....
Requiring his appointees who lead Executive Branch departments and rulemaking agencies to conduct the significant business of the agency in public, so that any citizen can watch a live feed on the Internet as the agencies debate and deliberate the issues that affect American society....
Lifting the veil from secret deals in Washington with a web site, a search engine, and other web tools that enable citizens easily to track online federal grants, contracts, earmarks, and lobbyist contacts with government officials.
Giving the American public an opportunity to review and comment on the White House website for five days before signing any non-emergency legislation.
Employing technologies, including blogs, wikis and social networking tools, to modernize internal, cross-agency, and public communication and information sharing to improve government decision-making.
In other words:
I'm assuming Barack is not interested in setting up a facebook group for just members of Congress.
No, that's exactly what he's going to do -- maybe not Congress, as he can't really control them, but at least the White House. Maybe not Facebook, but something at least as open and public.
First, literally, I don't see TFA. I see TFBE -- The Fine Blog Entry -- which quotes the letter, but doesn't link to it.
But I'll work with what I have:
OpenDocument currently lacks formula definitions for spreadsheets.... Many core financial functions in spreadsheets are undefined except for actual Excel output. That output varies by version and service pack of MS Office. What happens if OpenDocument and OpenXML reach different definitions of those functions?
Then OpenDocument is the correct, standard definition, and OpenXML will be even further from standardization.
The fact that Excel output varies by version and service pack, and is sometimes downright wrong, is all the more reason to ignore it. Approximate it, maybe, to make porting easier. Write a compatibility layer, even. But don't push through an entire second document spec, which is so deeply flawed in so many ways, just to make us match one particular iteration of Excel output.
Oh, and Excel output varies by version and service pack. WTF makes this tool think Microsoft will even try to adhere to a standard, even if it's their own?
In addition, ODF doesn't yet support "legacy features of Microsoft formats," he added. "That will be easier with a formal definition of those features."
It certainly would, wouldn't it?
Except for the fact that the OOXML spec doesn't include them. In all its six thousand fucking pages, not one mention of how, exactly, to implement LineSpacingLikeWord95. And what's he proposing -- delay OOXML until this can be included in the spec, and thus make it, what, twelve thousand pages? Or push it through in the faith (hah!) that Microsoft will add it to the next version of OOXML?
Consider, also, that there is a right way to do this: Styles. Extend the style system to support this quirky behavior. Support quirky behavior in an abstract way. Then, put the actual definition of LineSpacingLikeWord95 in the document itself, as a style. Translating back is easy, too -- just look for styles flagged that way, or just styles that happen to match the original format's quirk.
It would take some work, sure. But it would be pushing the work back to Microsoft and Office, not to ISO and any potential other implementations. And it would mean we don't have to carry this legacy crap with the format forever -- eventually, there will be no more Word95 documents, and no implementation will have to care that LineSpacingLikeWord95 corresponds to an actual way of saving a Word95.doc -- just that it should look a particular way.
It's pretty rich for people to complain that Microsoft used undocumented formats and then after they document the format complain that it contains cryptic legacy stuff.
Yeah, that's what we call "not documenting the format."
Oh, and yeah, great, they documented the format. But it is NOT something that should be accepted as a standard. BF is a documented programming language, but if you had to pick a standard language, would you pick BF, if there was, oh, any other alternative?
The cryptic legacy stuff is actually is actually their best trade secret, it's something that millions of third party documents rely on and only MS Office knows how to read.
What is so difficult about the two words "open" and "standard"? A proprietary trade secret is antithetical to that. Relying on proprietary trade secrets in a proposed "open standard" makes it neither.
And if you want something that allows you to convert a current MS Office document to it and convert back without loss of formatting, that something needs a way to store all the legacy attributes.
Which in no way mandates that these legacy attributes also be completely opaque to every implementation except one.
Oh, by the way, we have a way to store odd formatting, and maintain backwards translateability -- styles. Extend the style system to where it can support weird shit like adjusting the "justify" algorithm, and store a SpacingLikeWordPerfectForDos (or whatever) style, in the document, with some special flag to indicate how it translates back into legacy formats (like Word 95 binary.doc).
Except that, as you say, the cryptic legacy stuff is a trade secret. Which is why we really don't want it ratified as any kind of open standard, as it is, quite simply, not open.
I'm sorry, but you can't have it both ways. Either you've got trade secrets based on your file format, or you have an open standard. Not both.
I still don't see a hypervisor'd Linux being useless here -- or a Linux which has been modified such that certain parts of it are deterministically realtime (including drivers), and certain parts are not.
Take a task which needs to be hard realtime, but for which you'd like to see reports. The task continues to operate at hard realtime, on whatever hard realtime layer is needed, throwing log messages into a ring buffer in a realtime-compliant, deterministic way.
Another task, which doesn't need to be realtime at all, attempts to pull stuff out of the ring buffer and send it over the network to a logging machine, or to local storage, or whatever. Maybe it even generates fancy reports, flips blinkenlights, etc.
Worst case, the reporting/logging task falls behind, and generates an error -- but the hard-realtime task just keeps chugging along, and doesn't even notice.
That's probably a bit contrived, and certainly naive, but I do imagine there are other, similar cases where you need some tasks to be realtime, and some tasks can lag. And if it can be done without a hypervisor, that's probably a performance gain.
It is the industry standard that a "song" is a four-minute song encoded at 128 kbps, or a file 4 MB in size.
Where is this stated explicitly, such that if comcast terminates me, and I haven't used however many "songs" they claim, I can sue them for false advertising?
And more importantly, why can't they just state it it megs/gigs, like the rest of the world??? Confusing, at best.
Regarding the webserver, I am arguing the opposite, though. The single-threaded, event-driven architecture allows the server itself to remain relatively lightweight.
I'm arguing that you have too narrow a definition of "threads". Any webserver that takes advantage of multiple processors is either having multiple threads/processes actually listening to port 80, or is a single process listening to port 80 and load-balancing between multiple backend threads/processes.
And I'm arguing that if such a coarse model truly can be made to work, it might be worth investigating how to do it in more places. (I think Erlang is an example of that model.)
I don't know if it's necessary to hide the parallelization from programmers (Erlang) or to expose just the bare minimum (fork(), etc).
Well, Erlang doesn't hide it from the programmers, it just makes it easier to work with.
And I would argue that we already have fork() and friends, and POSIX threads, and locks/semaphores, etc. And all of that is needed. But we also need something built on top of that, which provides sufficient abstractions for the most common ways of threading -- and we need to pick some common ways of threading.
A simple example: Map/reduce. I'd like to be able to take a chunk of data, and call an iterator on it -- like Ruby's each() or map() -- except have this iterator automatically span processors. Specifically, it would ideally spawn n threads (where n is the number of CPUs), and keep them busy, but as a programmer, I shouldn't have to worry about it. I should be able to do something like:
That works right now. What I want, though, is some variant which runs each iteration in parallel -- as you can see, even in that contrived example, it should be able to use at least four cores. Under the hood, if upcase is doing something similar (splitting a string into characters, each character gets a thread), then it could use 13 cores.
Obviously, the above example would actually suffer from that approach -- spawning and synchronozing threads would take far more work than simply brute-forcing it in one thread. But you can see the pattern, and how it might be useful...
Well, you know. If you don't like my copying and pasting, don't read my stuff. I mean, nobody is twisting your arm.
I'm doing two things here: I'm warning other people away from being drawn into what looks very much like a dead end, and I'm offering a suggestion to you -- if your idea is really and truly revolutionary, you should be able to find a better way to communicate it. Copying/pasting hyperbole -- going out of your way to pick fights -- is not going to help you.
It's going to be relevant soon enough because threads are a major pain in the ass.
Done right, they can be a beautiful thing. And you have yet to demonstrate that this thing you're building is any better.
BTW, it does not take that long to design and build a new processor anymore, even if it's a multicore processor. It can be done in months if you have a firm idea in mind.
You don't even have the software right now. I can't find a download link, and your forum is down, so I don't see any discussion happening. Right now, it looks pretty much like vaporware -- maybe designed to attract VCs?
Come back when you have something I can play with.
(Oh, and a GUI for programming seems like a bad idea. That might just be a gut feeling, though.)
And you're wrong about having to read all my stuff to find out that we need a whole new architecture since I mentioned in the original post that the computer industry needs to abandon Babbage's sequential model and move to a new computing model.
Which could have been talking about a new software model, just as easily.
I like the flex/javascript solution. Just one thread - with asynchronous-like behaviour through events.
Which means your own app can't be threaded. Which is fine, for many things, and unacceptable, for many others.
It means there are no race conditions
I suppose it depends how you define "race condition", but they certainly do exist, especially when you get better at wrapping that asynchronous behavior. I've certainly written JavaScript apps which could be broken badly by pressing a particular key too quickly.
The benefit is, of course, that you don't have to think about certain types of synchronization at all. The entire system is effectively locked while your one thread executes. If you need to be sure a particular object isn't modified until you're done with it, simply don't make any asynchronous calls until... But you may have to make those asynchronous calls anyway. Which means you'll probably want to add some sort of "lock" of your own -- a boolean that says "busy" or something.
Basically, Javascript is cooperative multitasking. And you still have problems -- I would much rather see parallel programming solved at a more fundamental level.
I hope, in the future, that both these technologies allow you to create a separate "process" (thread but with different memory context) that executes asychronously and returns the results on the main event queue.
See, I hate Microsoft for the same reasons. They used all these sneaky/cool tactics to stick it to IBM, and then they became the next IBM, only worse.
And they still haven't kicked their habits of being reckless, successful, and dishonest, and of selling products they don't have.
And I do like a few corporate policies from Google, but I hate most from Apple these days. Google spends millions of dollars every year on "Summer of Code", which is pretty much no-strings-attached open source development. Contrast this to Apple, which, when they do provide open source, it's still on their terms, and the open version often lags behind the commercial version. (Example: Darwin.)
That, and recently, Google is developing Android, a completely open mobile platform that also happens to be device-independent -- it could even be ported to the iPhone. Apple, on the other hand, has given us the iPhone, which finally has an SDK, under terms that make Microsoft look benign.
It helps that Google and Apple have good products, but between those three, it's pretty obvious to me which one is doing the most for me.
Completely offtopic, but when on Windows, I use the IETab Firefox extension. I'd rather use Firefox for absolutely everything that I can, and just have a few open tabs with the IE engine, rather than a completely separate browser. Configured right, and users won't really notice.
Also, complain loudly to whoever's responsible for those apps. It seems likely they won't care, but it seems equally likely that they're just waiting for enough people to complain, so they can make the case to their bosses.
Wow, I thought it was interesting the first time I saw you say it -- but a quick Google turns it up again.
Really, a copy/paste troll on threading? WTF?
And yes, I'm calling it a troll unless you stop quoting that "150 years after Charles Babbage" BS, and start making your point within the comment, instead of in a rambling five-page blog post which links to a rambling whitepaper, at the end of which, we finally get a vague idea of what you might be talking about -- and we find that it's not really relevant to the real world unless we adopt a whole new (as-yet uninvented) hardware architecture.
It depends on the application. Some applications simply benefit from running in realtime. And some applications don't really scale well by breaking them up into individual processes. Some applications want to use as much CPU as you can throw at them -- a web app, for instance, had better be able to handle another few (dozen?) app servers if you get Slashdotted.
Also: Management of threads is mostly hard because we're mostly still using such low-level tools to do it. Semaphores, locks, and threads are the equivalent of GOTOs, labels, and pointers. While you can build a higher-level system (message-passing, map/reduce, coroutines) out of semaphores, locks, and threads, I'd argue that's like writing everything in GOTOs instead of doing a proper for loop -- or using a for loop instead of a proper Ruby-style "each" iterator. At the risk of abusing my analogy, yes, sometimes you do want to get under the hood (pointers, threads), but in general, it's much safer, saner, and not that much less efficient to use modern parallel programming concepts.
There's still some real problems with pretty much any threaded system, but I suspect that a lot of the bad rap threads get is from insufficient threading tools.
Oh, and about that webserver -- using more than one process is pretty much like using more than one thread, and I'd say weighs about the same in this discussion. Webservers, so far, are able to get away with using one thread (or process, doesn't matter) per request (and queuing up requests if there's too many), so that's a bit less of a problem than, say, raytracing, compiling, encoding/decoding video, etc.
The reality is that Linux has little to offer to the inexperienced user.
Face it, no OS has much to offer to the inexperienced user. The question is, how much does it take to become an experienced user? Or how much does the OS get in your way if you're inexperienced?
The same novice that is seen disconcerted by the impossibility to do a simple one copy-paste between QT and GTK applications.
Been doing this for years.
Go out and ask to the people how they install a program that does NOT have packages for its distribucción
Simple: Treat the distribution as an OS. If it doesn't have a native package for Ubuntu, then as a novice user, assume it doesn't support Ubuntu.
Now, I dare you to find a slicker way to install and maintain programs than Synaptic.
Explain him why in his Ubuntu, Kubuntu or Fedora cannot see many web pages: he must download the Flash and the Java plugin, in order then to install them with complicated commands.
Oh please:
apt-get install sun-java6-jre flashplugin-nonfree
And there's a GUI for that, too, if you need it. I think it prompts you on first boot now.
Also make him know that he won't be able to listen its MP3, WMA and WMV files.
Except he can -- again, absurdly simple to enable. First time you click on an MP3, you'll get a prompt that'll guide you through installing the necessary packages.
You're not even trying, are you?
Tell to the flaming buyer of a new AMD64 how he can play flash games.
Worst case? Tell them to install a 32-bit OS. Not as if they'd be worse off than in Windows.
besides, the drivers don't come in the distributions...becuase of the fucking freedom
Again, only a few clicks away. And once they're installed, they'll actually auto-update, and stay updated.
Believe it or not, installing XP on this laptop was worse -- tried downloading the drivers from nvidia.com, and they didn't work. The Toshiba site only had Vista drivers. Had to go to an old Toshiba UK site to find any. On Linux? Damned-near plug'n'play.
The proof of the free software failure is seen also in the professional world...
And then you go on to list a few apps that you don't like, but which do, indeed, prove that these things exist. Oh, and Maya has a Linux port.
In the software development industry there's not a single decent RAD tool.
Rails.
now prefer the most powerful system for software development: Microsoft Visual Studio.NET.
Which also can only be used reasonably on a machine with 2 gigs of RAM. May as well use Eclipse.
Accounting software? In Linux? There's not software in this area.
For business-level, maybe not. Personal-level, there's Gnucash and KMyMoney.
If Linux is free (in both senses)...Why the high computers-makers don't preinstall it (just a 1% make that)?
Dell does.
He wants to install his webcam without recompiling the kernel.
Literally plugged a webcam into a vanilla Kubuntu, had it running in Kopete with no tweaking whatsoever.
And at that point, you descend completely into a pointless rant, that makes me wonder exactly what Linux people you've been hanging out with -- if, indeed, you know anything about Linux at all. You make some good points, but you lose all credibility when you rant about problems that were fixed 2+ years ago, or actually complain about things that Linux does better than Windows.
There was an explanation awhile ago as to why they can't shape on Cable. I don't remember what it was, but there was a very good reason for actually killing connections.
While I do agree that Comcast is incompetent at best -- seriously, WTF are they doing telling us our limits in units of songs, emails, or photos? -- I'm just trying to get the facts straight.
If someone walks down into Harlem and says "A well-hung nigger is the one hanging from the nearest tree", I'll just sit back and watch.
People with principles will use their judgement rather than blindly follow their "freedom of speech" dogma to self-defeating extremes.
And yet, in the next breath:
Principles come with responsibilities, and one of those responsibilities is to make sure that liars don't stand unchallenged.
Freedom of speech is the very mechanism by which you challenge those liars.
Oh, and by the way: There are more of them than there are of us. If you take away freedom of speech, which speech do you suppose will end up being protected? Did you honestly think it would be sane, rational, truthful speech?
No, take away freedom of speech, and we'd both be burned as heretics.
By the way, I think Dawkins is a bit of a lunatic, and a fundamentalist in his own right, but he has said some interesting things. Despite that I don't agree with everything he says, I'm glad he's allowed to say them -- not just because of some abstract ideology, but because I actually think my life is better for hearing some of these things. Yes, even some of the fundamentalist, dogmatic drivel that I absolutely disagree with.
I need coffee before I'll really understand this, but here's a first attempt:
Despite the undeniable truth that Jacobsons TCP congestion avoidance algorithm is fundamentally broken, many academics and now Net Neutrality activists along with their lawyers cling to it as if it were somehow holy and sacred. Groups like the Free Press and Vuze (a company that relies on P2P) files FCC complaints against ISPs (Internet Service Providers) like Comcast that try to mitigate the damage caused by bandwidth hogging P2P applications by throttling P2P.
Ok, first of all, that isn't about TCP congestion avoidance, at least not directly. (Doesn't Skype use UDP, anyway?)
But the problem here, I think, is that George Ou is assuming that Comcast is deliberately targeting P2P, and moreover, that they have no choice but to deliberately target P2P. I'd assumed that they were simply targeting any application that uses too many TCP connections -- thus, BitTorrent can still work, and still be reasonably fast, by decreasing the number of connections. Make too many connections and Comcast starts dropping them, no matter what the protocol.
They tell us that P2P isnt really a bandwidth hog and that P2P users are merely operating within their contracted peak bitrates. Never mind the fact that no network can ever support continuous peak throughput for anyone and that resources are always shared, they tell us to just throw more money and bandwidth at the problem.
Well, where is our money going each month?
But more importantly, the trick here is that no ISP guarantees any peak bitrate, or average bitrate. Very few ISPs even tell you how much bandwidth you are allowed to use, but most reserve the right to terminate service for any reason, including "too much" bandwidth. Comcast tells you how much bandwidth you may use, in units of songs, videos, etc, rather than bits or bytes -- kind of insulting, isn't it?
I would be much happier if ISPs were required to disclose, straight up, how much total bandwidth they have (up and down), distributed among how many customers. Or, at least, full disclosure of how much bandwidth I may use as a customer. Otherwise, I'm going to continue to assume that I may use as much bandwidth as I want.
But despite all the political rhetoric, the reality is that the ISPs are merely using the cheapest and most practical tools available to them to achieve a little more fairness and that this is really an engineering problem.
Yes, it is a tricky engineering problem. But it's also a political one, as any engineering solution would have to benefit everyone, and not single out individual users or protocols. Most solutions I've seen that accomplish this also create a central point of control, which makes them suspect -- who gets to choose what protocols and usage patterns are "fair"?
Under a weighted TCP implementation, both users get the same amount of bandwidth regardless of how many TCP streams each user opens. This is accomplished by the single-stream application tagging its TCP stream at a higher weight than a multi-stream application. TCP streams with higher weight values wont be slowed as much by the weighted TCP stack whereas TCP streams with smaller weight values will be slowed more drastically.
Alright. But as I understand it, this is a client-side implementation. How do you enforce it?
At first glance, one might wonder what might prompt a P2P user to unilaterally and voluntarily disarm his or her multi-stream and persistence cheat advantage by installing a newer TCP implementation.
Nope. What I wonder is why a P2P user might want to do that, rather than install a different TCP implementation -- one which tags every single TCP connection as "weighted".
Oh, and who gets to tag a connection -- the source, or the destination? Remember that on average, some half of th
I find it annoying when people try to point out the hypocrisy of "Slashdotters" without citing individual people who are hypocritical that way. We are individuals, and despite the apparent groupthink, we can actually disagree. I don't agree with you that all Slashdotters are the same, and I don't agree with GP that fundie talk shows should actually be censored. Oh, and I don't agree with pretty much anything fundie talk shows have to say, but I will defend to my death their right to say it.
But nuance (sanity?) like that is completely lost when you lump us all in a group like that. Good job.
As to the lying about the product release, every company does that. If you hate Apple for it, you'd better hate others for it, too.
Oh, I do hate the others who do that -- or rather, I hate that they do that. I'm certainly no anti-Mac fanboy, assuming there is such a thing.
Just pointing out that it's habitual, and part of Apple's entirely closed culture. I'd even go so far as to say most Apple products are lied about in that way.
2k was essentially NT 5.0, and NT was already a good OS before that. 2k was just the version that actually obsoleted 95/98/ME, by being reasonably compatible with all the 95/98/ME stuff.
Also, before that, I would easily have argued that 95/98/ME was better than OS9, although Linux beat them both.
95/98/ME lacked basic concepts like user-level security -- sure, you could create separate users, but all you had to do is hit ESC at the password prompt, and you'd login as administrator -- and the filesystem itself (FAT32) lacked any concept of per-user file permissions, so you could access everyone's files anyway.
But hey, at least it actually had memory segmentation. Every Mac OS before OS9, if I remember, did not enforce which memory belonged to which app. Thus, one broken app could bring down the entire system, hard -- or just go play in some other app's memory and make it crash. It also allowed for some... interesting third-party apps. I remember one implementing RAM compression and a swapfile, so that you wouldn't get "out of memory" errors by running out of physical RAM. (The "compression" was the interesting part, to me.)
Then, 2k and OS X -- but hey, 2k was several months earlier than OS X, and it was based on (and fairly close to) NT, whereas OS X was based on (and not at all close to) BSD. I'd also argue that 2K isn't really that much worse than XP, though I'd certainly choose XP -- whereas OS X pretty much sucked until 10.3.
The megahertz myth that you referenced, however, has some legitimacy. The biggest problem with the megahertz myth phenomenon is that prior to the Intel switch, there was no good way to measure it. You pretty much had to use two machines and decide whether one felt more sluggish...
I suppose you could also use portable apps, or portable OSes. Put Linux on a PowerPC Mac and on an Intel PC, and see which one benchmarks faster.
What I find most hypocritical is that Apple, and in particular, Steve Jobs, habitually lie about what they have in the pipe, to keep it a suprise. I mean, there was a case of Steve Jobs being asked specifically about the possibility of Intel, a few months before the Intel macs came out, and he dismissed it out of hand -- and believe me, it took a lot more than a few months to port it.
That, and up until the day the Intel macs started coming out, and even a few days after that, Apple's G5 site was talking about its "Intel-crushing performance." Oh, the irony.
I think the reality is, PowerPC was a better architecture, but no one was putting any effort into developing it. All the R&D dollars were going into Intel and compatibles. So even if a PPC was twice as efficient, an Intel was more than twice the megahertz, so it won for sheer brute force. (Example: The fastest PPC laptop I saw was a 1.67 ghz G4. Now they're selling dual 2ghz Intels -- I'm sorry, but the G4 is not going to be efficient enough to make up that difference.)
Slashdot Mirror
From his website:
In other words:
No, that's exactly what he's going to do -- maybe not Congress, as he can't really control them, but at least the White House. Maybe not Facebook, but something at least as open and public.
First, literally, I don't see TFA. I see TFBE -- The Fine Blog Entry -- which quotes the letter, but doesn't link to it.
But I'll work with what I have:
Then OpenDocument is the correct, standard definition, and OpenXML will be even further from standardization.
The fact that Excel output varies by version and service pack, and is sometimes downright wrong, is all the more reason to ignore it. Approximate it, maybe, to make porting easier. Write a compatibility layer, even. But don't push through an entire second document spec, which is so deeply flawed in so many ways, just to make us match one particular iteration of Excel output.
Oh, and Excel output varies by version and service pack. WTF makes this tool think Microsoft will even try to adhere to a standard, even if it's their own?
It certainly would, wouldn't it?
Except for the fact that the OOXML spec doesn't include them. In all its six thousand fucking pages, not one mention of how, exactly, to implement LineSpacingLikeWord95. And what's he proposing -- delay OOXML until this can be included in the spec, and thus make it, what, twelve thousand pages? Or push it through in the faith (hah!) that Microsoft will add it to the next version of OOXML?
Consider, also, that there is a right way to do this: Styles. Extend the style system to support this quirky behavior. Support quirky behavior in an abstract way. Then, put the actual definition of LineSpacingLikeWord95 in the document itself, as a style. Translating back is easy, too -- just look for styles flagged that way, or just styles that happen to match the original format's quirk.
It would take some work, sure. But it would be pushing the work back to Microsoft and Office, not to ISO and any potential other implementations. And it would mean we don't have to carry this legacy crap with the format forever -- eventually, there will be no more Word95 documents, and no implementation will have to care that LineSpacingLikeWord95 corresponds to an actual way of saving a Word95 .doc -- just that it should look a particular way.
Yeah, that's what we call "not documenting the format."
Oh, and yeah, great, they documented the format. But it is NOT something that should be accepted as a standard. BF is a documented programming language, but if you had to pick a standard language, would you pick BF, if there was, oh, any other alternative?
What is so difficult about the two words "open" and "standard"? A proprietary trade secret is antithetical to that. Relying on proprietary trade secrets in a proposed "open standard" makes it neither.
Which in no way mandates that these legacy attributes also be completely opaque to every implementation except one.
Oh, by the way, we have a way to store odd formatting, and maintain backwards translateability -- styles. Extend the style system to where it can support weird shit like adjusting the "justify" algorithm, and store a SpacingLikeWordPerfectForDos (or whatever) style, in the document, with some special flag to indicate how it translates back into legacy formats (like Word 95 binary .doc).
Except that, as you say, the cryptic legacy stuff is a trade secret. Which is why we really don't want it ratified as any kind of open standard, as it is, quite simply, not open.
I'm sorry, but you can't have it both ways. Either you've got trade secrets based on your file format, or you have an open standard. Not both.
Skim the summaries, and occasionally there's something worth clicking through. It's not a new idea at all.
It also seems like a bad idea, if it's based on this premise:
And it's much easier to game human systems than algorithmic ones, I expect.
I still don't see a hypervisor'd Linux being useless here -- or a Linux which has been modified such that certain parts of it are deterministically realtime (including drivers), and certain parts are not.
Take a task which needs to be hard realtime, but for which you'd like to see reports. The task continues to operate at hard realtime, on whatever hard realtime layer is needed, throwing log messages into a ring buffer in a realtime-compliant, deterministic way.
Another task, which doesn't need to be realtime at all, attempts to pull stuff out of the ring buffer and send it over the network to a logging machine, or to local storage, or whatever. Maybe it even generates fancy reports, flips blinkenlights, etc.
Worst case, the reporting/logging task falls behind, and generates an error -- but the hard-realtime task just keeps chugging along, and doesn't even notice.
That's probably a bit contrived, and certainly naive, but I do imagine there are other, similar cases where you need some tasks to be realtime, and some tasks can lag. And if it can be done without a hypervisor, that's probably a performance gain.
Where is this stated explicitly, such that if comcast terminates me, and I haven't used however many "songs" they claim, I can sue them for false advertising?
And more importantly, why can't they just state it it megs/gigs, like the rest of the world??? Confusing, at best.
I'm arguing that you have too narrow a definition of "threads". Any webserver that takes advantage of multiple processors is either having multiple threads/processes actually listening to port 80, or is a single process listening to port 80 and load-balancing between multiple backend threads/processes.
And I'm arguing that if such a coarse model truly can be made to work, it might be worth investigating how to do it in more places. (I think Erlang is an example of that model.)
Well, Erlang doesn't hide it from the programmers, it just makes it easier to work with.
And I would argue that we already have fork() and friends, and POSIX threads, and locks/semaphores, etc. And all of that is needed. But we also need something built on top of that, which provides sufficient abstractions for the most common ways of threading -- and we need to pick some common ways of threading.
A simple example: Map/reduce. I'd like to be able to take a chunk of data, and call an iterator on it -- like Ruby's each() or map() -- except have this iterator automatically span processors. Specifically, it would ideally spawn n threads (where n is the number of CPUs), and keep them busy, but as a programmer, I shouldn't have to worry about it. I should be able to do something like:
That works right now. What I want, though, is some variant which runs each iteration in parallel -- as you can see, even in that contrived example, it should be able to use at least four cores. Under the hood, if upcase is doing something similar (splitting a string into characters, each character gets a thread), then it could use 13 cores.
Obviously, the above example would actually suffer from that approach -- spawning and synchronozing threads would take far more work than simply brute-forcing it in one thread. But you can see the pattern, and how it might be useful...
I'm doing two things here: I'm warning other people away from being drawn into what looks very much like a dead end, and I'm offering a suggestion to you -- if your idea is really and truly revolutionary, you should be able to find a better way to communicate it. Copying/pasting hyperbole -- going out of your way to pick fights -- is not going to help you.
Done right, they can be a beautiful thing. And you have yet to demonstrate that this thing you're building is any better.
You don't even have the software right now. I can't find a download link, and your forum is down, so I don't see any discussion happening. Right now, it looks pretty much like vaporware -- maybe designed to attract VCs?
Come back when you have something I can play with.
(Oh, and a GUI for programming seems like a bad idea. That might just be a gut feeling, though.)
Which could have been talking about a new software model, just as easily.
Which means your own app can't be threaded. Which is fine, for many things, and unacceptable, for many others.
I suppose it depends how you define "race condition", but they certainly do exist, especially when you get better at wrapping that asynchronous behavior. I've certainly written JavaScript apps which could be broken badly by pressing a particular key too quickly.
The benefit is, of course, that you don't have to think about certain types of synchronization at all. The entire system is effectively locked while your one thread executes. If you need to be sure a particular object isn't modified until you're done with it, simply don't make any asynchronous calls until... But you may have to make those asynchronous calls anyway. Which means you'll probably want to add some sort of "lock" of your own -- a boolean that says "busy" or something.
Basically, Javascript is cooperative multitasking. And you still have problems -- I would much rather see parallel programming solved at a more fundamental level.
It sounds like coroutines. Am I close?
See, I hate Microsoft for the same reasons. They used all these sneaky/cool tactics to stick it to IBM, and then they became the next IBM, only worse.
And they still haven't kicked their habits of being reckless, successful, and dishonest, and of selling products they don't have.
And I do like a few corporate policies from Google, but I hate most from Apple these days. Google spends millions of dollars every year on "Summer of Code", which is pretty much no-strings-attached open source development. Contrast this to Apple, which, when they do provide open source, it's still on their terms, and the open version often lags behind the commercial version. (Example: Darwin.)
That, and recently, Google is developing Android, a completely open mobile platform that also happens to be device-independent -- it could even be ported to the iPhone. Apple, on the other hand, has given us the iPhone, which finally has an SDK, under terms that make Microsoft look benign.
It helps that Google and Apple have good products, but between those three, it's pretty obvious to me which one is doing the most for me.
Completely offtopic, but when on Windows, I use the IETab Firefox extension. I'd rather use Firefox for absolutely everything that I can, and just have a few open tabs with the IE engine, rather than a completely separate browser. Configured right, and users won't really notice.
Also, complain loudly to whoever's responsible for those apps. It seems likely they won't care, but it seems equally likely that they're just waiting for enough people to complain, so they can make the case to their bosses.
Wow, I thought it was interesting the first time I saw you say it -- but a quick Google turns it up again.
Really, a copy/paste troll on threading? WTF?
And yes, I'm calling it a troll unless you stop quoting that "150 years after Charles Babbage" BS, and start making your point within the comment, instead of in a rambling five-page blog post which links to a rambling whitepaper, at the end of which, we finally get a vague idea of what you might be talking about -- and we find that it's not really relevant to the real world unless we adopt a whole new (as-yet uninvented) hardware architecture.
Maybe. I think. That was a LOT of skimming.
It depends on the application. Some applications simply benefit from running in realtime. And some applications don't really scale well by breaking them up into individual processes. Some applications want to use as much CPU as you can throw at them -- a web app, for instance, had better be able to handle another few (dozen?) app servers if you get Slashdotted.
Also: Management of threads is mostly hard because we're mostly still using such low-level tools to do it. Semaphores, locks, and threads are the equivalent of GOTOs, labels, and pointers. While you can build a higher-level system (message-passing, map/reduce, coroutines) out of semaphores, locks, and threads, I'd argue that's like writing everything in GOTOs instead of doing a proper for loop -- or using a for loop instead of a proper Ruby-style "each" iterator. At the risk of abusing my analogy, yes, sometimes you do want to get under the hood (pointers, threads), but in general, it's much safer, saner, and not that much less efficient to use modern parallel programming concepts.
There's still some real problems with pretty much any threaded system, but I suspect that a lot of the bad rap threads get is from insufficient threading tools.
Oh, and about that webserver -- using more than one process is pretty much like using more than one thread, and I'd say weighs about the same in this discussion. Webservers, so far, are able to get away with using one thread (or process, doesn't matter) per request (and queuing up requests if there's too many), so that's a bit less of a problem than, say, raytracing, compiling, encoding/decoding video, etc.
I was bored, and I like cookies.
Figured Vista hadn't been out long enough for this to be really ancient.
Face it, no OS has much to offer to the inexperienced user. The question is, how much does it take to become an experienced user? Or how much does the OS get in your way if you're inexperienced?
Been doing this for years.
Simple: Treat the distribution as an OS. If it doesn't have a native package for Ubuntu, then as a novice user, assume it doesn't support Ubuntu.
Now, I dare you to find a slicker way to install and maintain programs than Synaptic.
Oh please:
And there's a GUI for that, too, if you need it. I think it prompts you on first boot now.
Except he can -- again, absurdly simple to enable. First time you click on an MP3, you'll get a prompt that'll guide you through installing the necessary packages.
You're not even trying, are you?
Worst case? Tell them to install a 32-bit OS. Not as if they'd be worse off than in Windows.
Again, only a few clicks away. And once they're installed, they'll actually auto-update, and stay updated.
Believe it or not, installing XP on this laptop was worse -- tried downloading the drivers from nvidia.com, and they didn't work. The Toshiba site only had Vista drivers. Had to go to an old Toshiba UK site to find any. On Linux? Damned-near plug'n'play.
And then you go on to list a few apps that you don't like, but which do, indeed, prove that these things exist. Oh, and Maya has a Linux port.
Rails.
Which also can only be used reasonably on a machine with 2 gigs of RAM. May as well use Eclipse.
For business-level, maybe not. Personal-level, there's Gnucash and KMyMoney.
Dell does.
Literally plugged a webcam into a vanilla Kubuntu, had it running in Kopete with no tweaking whatsoever.
And at that point, you descend completely into a pointless rant, that makes me wonder exactly what Linux people you've been hanging out with -- if, indeed, you know anything about Linux at all. You make some good points, but you lose all credibility when you rant about problems that were fixed 2+ years ago, or actually complain about things that Linux does better than Windows.
There was an explanation awhile ago as to why they can't shape on Cable. I don't remember what it was, but there was a very good reason for actually killing connections.
While I do agree that Comcast is incompetent at best -- seriously, WTF are they doing telling us our limits in units of songs, emails, or photos? -- I'm just trying to get the facts straight.
Depends on context.
If someone walks down into Harlem and says "A well-hung nigger is the one hanging from the nearest tree", I'll just sit back and watch.
And yet, in the next breath:
Freedom of speech is the very mechanism by which you challenge those liars.
Oh, and by the way: There are more of them than there are of us. If you take away freedom of speech, which speech do you suppose will end up being protected? Did you honestly think it would be sane, rational, truthful speech?
No, take away freedom of speech, and we'd both be burned as heretics.
By the way, I think Dawkins is a bit of a lunatic, and a fundamentalist in his own right, but he has said some interesting things. Despite that I don't agree with everything he says, I'm glad he's allowed to say them -- not just because of some abstract ideology, but because I actually think my life is better for hearing some of these things. Yes, even some of the fundamentalist, dogmatic drivel that I absolutely disagree with.
I need coffee before I'll really understand this, but here's a first attempt:
Ok, first of all, that isn't about TCP congestion avoidance, at least not directly. (Doesn't Skype use UDP, anyway?)
But the problem here, I think, is that George Ou is assuming that Comcast is deliberately targeting P2P, and moreover, that they have no choice but to deliberately target P2P. I'd assumed that they were simply targeting any application that uses too many TCP connections -- thus, BitTorrent can still work, and still be reasonably fast, by decreasing the number of connections. Make too many connections and Comcast starts dropping them, no matter what the protocol.
Well, where is our money going each month?
But more importantly, the trick here is that no ISP guarantees any peak bitrate, or average bitrate. Very few ISPs even tell you how much bandwidth you are allowed to use, but most reserve the right to terminate service for any reason, including "too much" bandwidth. Comcast tells you how much bandwidth you may use, in units of songs, videos, etc, rather than bits or bytes -- kind of insulting, isn't it?
I would be much happier if ISPs were required to disclose, straight up, how much total bandwidth they have (up and down), distributed among how many customers. Or, at least, full disclosure of how much bandwidth I may use as a customer. Otherwise, I'm going to continue to assume that I may use as much bandwidth as I want.
Yes, it is a tricky engineering problem. But it's also a political one, as any engineering solution would have to benefit everyone, and not single out individual users or protocols. Most solutions I've seen that accomplish this also create a central point of control, which makes them suspect -- who gets to choose what protocols and usage patterns are "fair"?
Alright. But as I understand it, this is a client-side implementation. How do you enforce it?
Nope. What I wonder is why a P2P user might want to do that, rather than install a different TCP implementation -- one which tags every single TCP connection as "weighted".
Oh, and who gets to tag a connection -- the source, or the destination? Remember that on average, some half of th
RFID. Ok, maybe not quite a broadcast technology, but you were kind of asking for it :P
Are these the same Slashdotters?
I find it annoying when people try to point out the hypocrisy of "Slashdotters" without citing individual people who are hypocritical that way. We are individuals, and despite the apparent groupthink, we can actually disagree. I don't agree with you that all Slashdotters are the same, and I don't agree with GP that fundie talk shows should actually be censored. Oh, and I don't agree with pretty much anything fundie talk shows have to say, but I will defend to my death their right to say it.
But nuance (sanity?) like that is completely lost when you lump us all in a group like that. Good job.
Yeah, pretty much.
...aaaand it looks like you didn't read my post. Try again.
Oh, I do hate the others who do that -- or rather, I hate that they do that. I'm certainly no anti-Mac fanboy, assuming there is such a thing.
Just pointing out that it's habitual, and part of Apple's entirely closed culture. I'd even go so far as to say most Apple products are lied about in that way.
2k was essentially NT 5.0, and NT was already a good OS before that. 2k was just the version that actually obsoleted 95/98/ME, by being reasonably compatible with all the 95/98/ME stuff.
Also, before that, I would easily have argued that 95/98/ME was better than OS9, although Linux beat them both.
95/98/ME lacked basic concepts like user-level security -- sure, you could create separate users, but all you had to do is hit ESC at the password prompt, and you'd login as administrator -- and the filesystem itself (FAT32) lacked any concept of per-user file permissions, so you could access everyone's files anyway.
But hey, at least it actually had memory segmentation. Every Mac OS before OS9, if I remember, did not enforce which memory belonged to which app. Thus, one broken app could bring down the entire system, hard -- or just go play in some other app's memory and make it crash. It also allowed for some... interesting third-party apps. I remember one implementing RAM compression and a swapfile, so that you wouldn't get "out of memory" errors by running out of physical RAM. (The "compression" was the interesting part, to me.)
Then, 2k and OS X -- but hey, 2k was several months earlier than OS X, and it was based on (and fairly close to) NT, whereas OS X was based on (and not at all close to) BSD. I'd also argue that 2K isn't really that much worse than XP, though I'd certainly choose XP -- whereas OS X pretty much sucked until 10.3.
I suppose you could also use portable apps, or portable OSes. Put Linux on a PowerPC Mac and on an Intel PC, and see which one benchmarks faster.
What I find most hypocritical is that Apple, and in particular, Steve Jobs, habitually lie about what they have in the pipe, to keep it a suprise. I mean, there was a case of Steve Jobs being asked specifically about the possibility of Intel, a few months before the Intel macs came out, and he dismissed it out of hand -- and believe me, it took a lot more than a few months to port it.
That, and up until the day the Intel macs started coming out, and even a few days after that, Apple's G5 site was talking about its "Intel-crushing performance." Oh, the irony.
I think the reality is, PowerPC was a better architecture, but no one was putting any effort into developing it. All the R&D dollars were going into Intel and compatibles. So even if a PPC was twice as efficient, an Intel was more than twice the megahertz, so it won for sheer brute force. (Example: The fastest PPC laptop I saw was a 1.67 ghz G4. Now they're selling dual 2ghz Intels -- I'm sorry, but the G4 is not going to be efficient enough to make up that difference.)
Wait -- you have six thousand internal users, and you can't afford to hire one Linux geek to get them configured properly?
That's not entirely rhetorical, because it might be true, it just seems very odd.
It's not really open source at all. Parts of the kernel, and parts of the web browser. Beyond that, it's more locked down than Windows.
And if the iPhone is any indication, we can only expect more and more tightly held proprietary software, hardware, and patents from Apple.