Slashdot Mirror

But if things do go wrong it's really easy for me to ssh in and figure out what's going on because the Linux ecosystem is actually designed to anticipate errors, as opposed to my Mac where I can't tell the difference between an error and stupid interface design.

Sounds like a combination of lack of knowledge and bias, both on your part.

You can ssh into a Mac, too; or you can simply use any VNC Client to do "Screen Sharing" with a Mac (e.g., when on my work Win7 laptop, I use TightVNC). In fact, you can even launch a separate OS X session (using another User Account), and not disturb the GUI of the local user. Note: This capability even allows multiple VNC Clients to use the same Mac simultaneously. Try THAT with Windows out of the box...

Guess you need a little knowledge on remote Mac Administration. Here's an article on "Screen Sharing". And here's how to enable ssh on OS X (hint: the "Screen Sharing" (VNC) Enable is in the same place)

As Bitcoin alternatives go, I really liked the idea behind Namecoin. Not that it's likely to go anywhere, but it's something that puts some real backing, value, to the currency while simultaneously doing something to address the piss poor domain name allocation system that we have right now. Bitcoin is currently just floating on enthusiasm and greed, this would actually have some worth if people got behind it.

Firefox version history.

Note that the 3.6.x lineage continues to receive updates to fix security holes and improve stability. The most recent was March 13, 2012.

The download is here.

Install it, set the appropriate update options, and enjoy.

Best of all, I have yet to encounter an extension that doesn't work with it.

The trick is to disable extension version checking.

Most extensions will work fine, even when Firefox says they won't (based on the extension target version number not matching your Firefox version).

Namecoins should be able to help here: a decentralized DNS with its own currency for registering DNSes (which already proved to be useful as bitcoins). Nobody will be able to block some DNS if you bought it with namecoins, because this DNS is yours, right in your wallet.dat. And everyone who installed a namecoin based DNS client can use it. All DNS names are stored with transaction data within namecoin block chain. This blockchain is copied on thousands of client's PC connected in p2p network. This blockchain is encrypted with 60 PetaFLOPs/sec processing power, which makes them really safe! (namecoin difficulty is now 463897, compare that with PFLOPS used for bitcoin for example on bitcoinwatch).

No government will be able to stop namecoins, just like it's impossible to stop bitcoins. Well it's even better for namecoins. Bitcoins could theoretically be restricted by passing laws prohibiting banks to cooperate with mtgox. Namecoins on the other side do not need exchange with USD for DNS functionality to be working. Such exchange of course will be good, but you can buy namecoins using bitcoins on bitparking exhange, or mine them on slush's pool (the biggest namecoin/bitcoin pool). Domains are really cheap, you should be able to afford one for you just after few days or weeks of mining (depending on your power), or - since you can buy bitcoins now on mtgox without any problems, and because namecoins are really cheap, you can buy your own domain for less than 0.50USD. That is today's prices.

Anyway, I think that namecoins is the wave of the future to save us from any kind of censorship.

http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html
http://mtgox.com/ - get bitcoins BTC here
http://exchange.bitparking.com/ - buy namecoins NMC here
http://bitcoinwatch.com/

sure that's blatant ad. But I think namecoins are really going to help here.

well... time to start using namecoins http://dot-bit.org/Main_Page
http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html

Use an alternative to DNS, such as Namecoin. It's only a matter of time before RIAA/MPAA make their way to controlling the entire DNS.

Let's get this idea out so that it gets implemented and leads to the decentralization of the DNS process...

An approach that is currently in development is Namecoin. It's a decentralized DNS approach based on Bitcoin. Names are registered and stored in the namecoin blockchain. More information is available at the dot-bit project website. Currently the software is there for registering and looking up names. What's needed is easier to use software like browser plugins and DNS proxies that lookup via namecoin. Some of this is in progress like the proxy, DNS and whois capability provided by namecoin.us.

Take a look at 'Namecoin': http://www.bluishcoder.co.nz/2011/05/12/namecoin-a-dns-alternative-based-on-bitcoin.html

Nonsense.

First of all, Microsoft does *not* have "nothing to worry about" with H.264. Just because it pays tribute (er, licenses patents) from one organization does *NOT* mean that it's protected from all other organizations. In fact, once you demonstrate that you're willing to pay to one organization, others will start to show up to get some money too. For an analogy, look at the history of the Vikings; once people started paying tribute, the odds of looting parties showing up INCREASED. And we don't have to just use analogies; look at the recent history of sound codecs, specifically MP3. Microsoft paid big$ tribute for MP3, but Alcatel-Lucent sued Microsoft and won a record-breaking $1.52 billion in damages via a jury verdict. Now it's true that Microsoft got lucky in that one; in the MP3 case, a judge reversed the jury, a highly unusual event. If a judge hadn't reversed it, Microsoft would have paid $1.52 billion in additional damages for something it had ALREADY PAID LICENSE FEES for. And even so, Microsoft spent a FORTUNE in court on MP3, a codec that it was already paying license fees for. So it appears that "licensed" codecs have a HIGHER risk, not a lower risk, historically speaking. Wikipedia has more about the MP3 patent stuff.

Second of all, there's already been a lot of money and research spent to make sure that Ogg Theora is free of patent issues. Few things in life are "conclusively proven"; let's use realistic measures. The evidence, in this case, is really strong that Ogg is safe. Strictly speaking, it's not that Ogg Theora is patent-free, it's that all known required patents have been released under and irrevocable free license. That is actually a stronger legal position than simply "not knowing of any patents"... here we have a granted patent, which is then released. The Ogg folks spent $ to do their own legal searches, too, something standards bodies emphatically do NOT do, giving you additional protection. Most companies that claim that "Ogg has unknown patent issues" are basically flinging FUD; it's mainly a protest claimed by companies who have a vested interest (a kickback) from the patent licenses. In particular, it's my understanding that Apple *makes* money from the H.264 patents. So unsurprisingly, Apple works to lock everyone else into the patents they partly control, and actively works to *prevent* the use of open standards for codecs. But you don't need to buy into that.

Sure, it's always possible that there are unknown submarine patents, but submarine patents are risk to all codecs, including H.264; that is not specifically a risk to Ogg Theora. Indeed, H.264 is MORE dangerous. Because H.264 was developed in an environment where patents were permitted (for shame, ISO), and there was no *requirement* for an external patent search (ISO doesn't require it), there was an incentive to patent everything, both by the participating parties and by external parties. There have been a number of court cases about MP3, but none about Vorbis, which shows that once you let patents into a standards process, things can get really bad.

Someday, someone may find a patent problem with Ogg Theora, but this is highly unlikely. In contrast, we have hideous patent problems with H.264, today. Why worry about Ogg, when there's a wolf already in tent? We need to dump H.264 (with its KNOWN problems) and switch to Ogg (which has NO known problems). First step: Get the browsers to support Ogg Theora. Then websites can more rationally use the format. It's better for Microsoft's customers: They can then easily use an open standard. It's also better for Microsoft: If more people use an open standard, they won't be as beholden to the H.264 licensors and will reduce the risk of me-too lawsuits like that of Alcatel-Lucent.

There was also a patch for Firefox 3.0 that made it use gstreamer. Seems like Mozilla didn't like it though. :(

Javascript + svg?

Photo demo
Blobular

Photo demo converted to video demo
Info on video demo

Javascript + svg?

Photo demo
Blobular

Photo demo converted to video demo
Info on video demo

Scheme too!

http://www.bluishcoder.co.nz/2006/05/scheme-implementation-in-javascript.html

I think this is the link i am looking for (can't get there from work)
http://www.bluishcoder.co.nz/2008/09/javascript-space-invaders-emulator.html
the stuff referenced is about emulating assembler with js

Firefox will use the platform's normal video support according to this blog post. That is, DirectShow on Windows, QuickTime on Mac, and gstreamer on Linux. H.264 is supported by all of those with the proper plugins, but that gets us right back to the reason why the popular video sites do not use <embed> or <object> which sites used to do for video before FLV became popular and some sites still do: the client has to have the right codecs. Getting the user to have Flash installed is, in practice, easier than getting them to have the right video codecs despite how annoying the Flash requirement may be for the small minority of users who do not use Windows or Mac OS X or simply want the web to be sane and non-proprietary.

I hope to see the html 5 video support added for Fx3.1

You're almost certainly going to get it, with Ogg Theora support at the very least (a DirectShow backend for Windows, QuickTime backend for Mac OS X, and GStreamer backend for Linux are also in the works). But the real question that no one seems to be asking is, where is HTML 5 audio support? It's just as much a part of the specification, and Ogg Vorbis is well-known enough that corporate entities aren't so worried about patents. I've seen some work on it recently, but I'm not sure it's mature enough to make the deadline. HTML 5 audio and video support in Firefox 3.1 would be a dream though. Safari already has at least some support for both, and Opera has partial support for audio with video surely not far off. Internet Explorer is obviously going to take a long time to catch up, but I guess we can't have everything...

There are already Firefox builds that implement the element using ogg theora and vorbis - http://www.bluishcoder.co.nz/2007/12/new-enabled-experimental-firefox-builds.html

The problem with flash and great projects like gnash is that it will never be a full freely distributable implementation as long as we have draconian patent laws. Components such as flash video are patented. Likewise the silverlight won't be complete in a free distribution.

I think people need to get informed about what is happening in the open platform space. Check out the firefox3 builds with ogg theora support. This combined with canvas, svg and the hardware accelerated rendering via cairo we can see the platform for rich open media coming into place.

A demo that everyone should check out is the SVG theora demo A Rich Open Media Platform is already on its way ;) All we have to do is build some killer apps for it and push these open pieces into IE, safari etc. Instead of the other around where propitiatory components being pushed into open platforms.

its an uphill battle given the sudo standardization around flash... but ultimately free and open system have inherit advantages that will eventually outweigh the proprietary solutions in free flowing information environments... It's only a matter of time ;)

Thing is, I like the mozilla approach ( http://www.bluishcoder.co.nz/2007/02/offline-zimbr a-with-firefox.html ) better. I think it's because there's no need to install 3rd party apps and such. But thing is, as it seems Google is ahead in this, and if people start adopting it (remains to be seen) then the mozilla approach probably won't stir too much water when it's released.
 

You don't have to use XMLHttpRequest. You can dynamically add a script node to the document if you've got JavaScript you want to include from a different site.

Here's an example.

"Also, no even slightly popular browser supports client side scripting with Scheme, and most web hosts don't offer server-side scripting with it either."

JsScheme

Scheme hosting...sort of

Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.

This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of connections that it uses and this eats one of them up (Some versions of IE only use 2 connections). This could prevent other AJAX or normal HTTP requests from occurring.

The same problem exists with the 'hidden IFRAME' approach. One interesting workaround is to have a hidden flash applet on the page whose sole purpose is to create a persistent connection to the server. The server can send data to the flash applet which then calls javascript callbacks on the web page. This does not eat up a browser connection as flash has its own connection pool. As it's a normal socket you can also use any protocol for the events you want. The downside is that if the user goes through a strict firewall that only allows outgoing http traffic on port 80 you're stuck.

I describe some of the options here: More on Ajax and Server Push

Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections. It uses AFLAX which allows easy communication from Javascript to an embedded flash applet.

The approach I've gone for is to use the flash idea, falling back to a delayed AJAX call response, then to a hidden IFRAME depending on browser support. This approach does what you want - allowing the server to push to the client.