John Wiseman's photos of the fire in LA near his home, including...
"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.
It’s fascinating to note that we spend a massive amount of time focusing on making software malleable at compile/build time (Spring anyone?) but considerably less effort on ensuring similar flexibility post deployment making for brittleness in face of failure, upgrade, configuration changes, scaling etc.
You have to be real careful when you invest in some vendor's technology. Will they help or hinder getting you where you want to go.
Microsoft I gather is *real* scared of google, and so they try emulating a bunch of googlesque capabilities. As usual I have not read a lot about them, but this one about "live data" and "data wants to be free" caught my attention.
See, calendar information seems to me to be the data that *most* wants to be free, but isn't yet as free as it should be. Is calendar information now free from Microsoft?
Or is there motto: "Data wants to be free, and will be, unless we can lock it up in a proprietary server, obfuscate it in proprietary formats, and extort you to pay for a lot of client licenses to get to it using tools of our choice"?
Maybe things have changed -- please correct me if I am wrong, or explain why you don't need fully functional calendar information to be free.
The difference is, for an OS kernel, there really isn't any other way to benefit from multiple CPUs. But for Python, there is -- run multiple processes instead of threads!Yeah, I don't like threads one bit.
How much support does Python have (in the distribution or from other contributions) for starting and stopping processes on the same or other machines? And for communicating with them?
I am all for this approach, but little attention is being paid that I know of to programming this way, regarding "all the little things" that are needed to develop, test, and deploy concurrent, distributed systems. Not to mention "post modern" systems using various languages.
The "common language runtime folks" (clr/dlr and jvm, etc.) are salivating over using each others classes. We should be more interested in using each others processes.
Just because Java was once aimed at a set-top box OS that didn't support multiple address spaces, and just because process creation in Windows used to be slow as a dog, doesn't mean that multiple processes (with judicious use of IPC) aren't a much better approach to writing apps for multi-CPU boxes than threads.Even in the same address space it's better to pretend you're not. Java applets, etc. were aimed at the everyday developers, so why did the language designers give them such things as threads and locks? More out of habit and lack of questioning their hidden assumptions than anything else, I'd bet.
Yeah, it will be a good thing when we can do all our cross-platform, distributed process management stuff in IronicPython and/or Jython! (This might have been more interesting even five years ago. Now we know we could have been, and should be running in the *opposite* direction. Instead of running at full speed, we're still docked, with the steamliner facing the *wrong* direction.)
"Common Language Runtimes" -- phooey. Think broader. Patrick Mueller points to his investigations with Java in a comment to this post. Is Microsoft's CLR/DLR going to do a better job at cross-platform, distributed process management???
But if you're not pushing a bunch of hypertext down to my browser, you're not helping me explore the space.I agree with this. Nothing about the server should be specific to the client. Adobe promotes FDS (Flex Data Services) and there may be a time and place to use it (or not), but that's not "on the web".
I don't think developers should slide into the mode of piece-wise assembly of a bunch of widgets and wiring them up to the automated updaters keeping objects-in-sync across networks.
But taking a more web-oriented approach doesn't preclude using client stuff that's a bit more expressive than current popular browsers. There're good ajax apps and there're bad ajax apps. Same with other "RIA" technologies.
RIAs built on something like Flex and possibly Apollo, but using the web in the right way is appealing to me. Finding more simple ways to build the RIA part *and* get the most out of the web is an interesting challenge.
Fuzzy relays the state of the Jini world... great Java technology. Community is awful. Not easy to invest in that direction, when the signs of community since River started have been no better, or worse, than prior to that event.
On Thursday an email went out to arrange a get together on Monday at JavaOne. I will be down in SF on Thursday and Friday, but too late to change plans for Monday.
chromatic wonders about duplicating silverspoon on linux...
I’m not sure that making the life of the marketing department of a convicted monopolist which just loves to embrace, extend, and extinguish competition is the best way to spread freedom through software.Here's my deal: the MSFT community seems to hang on every word of every potential innovation from Redmond. The same is true to some extent in the Apple community, but to a far lesser extent. In part this could be so because MacOSX is based on Unix, and so the culture and innovations can cross over much more easily.
By and large Linux, Java, and the other various language-centered communities have the tools to innovate and the culture to innovate and *do* innovate more (in my preception - not formally measured) than the MSFT community.
And so would you rather your world be based on the governed pace of innovation from one large bureaucracy? Or would you rather have more freedom to move in directions and at a pace best suited to your market?
I can count all kinds of devices running Linux in my house, from several vendors. Not so for Windows. Getting silverspoon running compatible, not getting incompatible, etc. is not a good choice when given the choice to be more innovative, whether based on Adobe Flex/Apollo or anything else.
"Anything but MSFT." seems to be the most logical choice unless your market is already so caught up in MSFT's and your interests are so closely aligned with theirs.
They will *not* give you the tools you need unless that meets their needs. You choose.
Better to ignore them or force them to play your game, than try to play theirs.
Intel is concerned about their multicore roadmap. Chips could potentially have 32 cores within three years, but Intel may have to find other things to do with all their transistors until software can catch up and take better advantage of so many cores. This is not the first time software has failed to keep pace with hardware.
What contraints or propels software evolution vs. hardware evolution?
Is the actor model on the list of foundational topics in CS programs today?
Is the actor model about "objects"? Why or why not?
Is the actor model relevant today? Why or why not?
Are today's systems becoming more or becoming less like actor systems? Why or why not?