Slashdot Mirror

Running Firefox in a linux container, like Docker that saves no history could stop some of the tracking stored in your computer. Some extra addons (tor, https everywhere, etc) could improve a bit things.

Here is your brightness control. Brightness

Here's a fun one: search for PHP mysql_query code and glory at all of the input sanitizing they do.

ispc, OpenCL, and LLVM on the way. Failing that, you could of course use C++ and AVX intrinsics (which would be a good choice if you already have a load of SSE4/AVX optimised code lying about).

That's because it IS unwieldy, for anyone. Even EEG done properly is not cheap or simple, and EEG is not a wonderful method of visualising what is actually going on in the brain:

As the parent says, an EEG signal is complicated, noisy, and difficult to interpret. Many of the wild promises are just that; wild promises used to hype business plans. To get an idea of what's currently possible with state of the art research for implanted electrodes (which provide a much better signal than a surface EEG), the following nature video on research at Brown may help:

https://www.youtube.com/watch?feature=player_embedded&v=ogBX18maUiM .

If you are still interested, it is very possible to play with EEG signals at home. The OpenEEG project is one place to start. If you are interested in designing your own hardware, the ADS1299 provides much of the functionality in a single chip (and allows you to do much more of the filtering in software where you can play more tricks). Noise is a major issue. You'll want good electrodes (sintered silver-silver chloride are best) and some form of electrode gel. You'll also want to look into signal analysis techniques; this in an active area of research for EEGs. The book "Brain-Computer Interfaces: Principles and Practice" edited by Wolpaw and Wolpaw (ISBN 978-0195388855) provides a good overview.

A small group of us are currently working on an open-hardware EEG-controlled mouse that you can build at home. It's still at an early stage, but we have managed to move a cursor on screen to a series of targets (and show via bootstrapping that we're doing much better than chance). The designs for the board and software prototypes can be found here: https://github.com/ericherman/eeg-mouse . If you want to be notified when we have something a little less prototype-like, send one of us an email and we'll start a list. If you want a better description of where we're at, create an issue on github.

You *can* play with this at home - either with your own software/hardware or someone else's. Much like writing a speech recognition engine, however, if you plan on easy success you'll be disappointed, but if you plan on a challenge you'll have a lot of fun.

I don't understand why nobody mentioned Trac yet.

Depending on your configuration, you can get totally independent and distinct project environments for each project (e.g. paths, design, modules, rights, etc.) with as many git repositories as you'd like per project.
Basically, you define one master config with the minimum (or default) configuration and then overload/override it with specific settings in the project's configuration file.

You can further integrate this flow into a CI environment like Gerrit and build systems, as well as using the native (!) Eclipse Mylyn RPC plugin to access all your tickets without even leaving your IDE (however, it's not just an ugly browser window inside Eclipse like in redmine...!)

Here's a post-receive hook for gitolite that works for multiple repositories. (Read the discussion here.

Works f... awesome, especially, if you're sick of having part of your stuff in the db and the rest in the filesystem!

I think my favorite thing about Gitlab has to be the description that reads:

Self Hosted Git Management application. Create projects and repositories, manage access and do code review..

then has a link to the source code and installation instructions, both of which are hosted on....Github

At my company, we use Gitolite and I've only had good experiences with it.

https://github.com/sitaramc/gitolite/wiki

You know it, you love it. Just continue using Github (just on your own servers)

You might want to look into HipHop a bit. It's rather quite nice.

Also the fact that a behemoth like FB can run as it is written in PHP is more of a commentary on the value of your post.

At one level, you're toast, right? You need a burner phone you bought with cash, without using ID, and to activate it without linking it to your person. You need to never have it with you at your commons places to be (house, work, coffeeshop on the corner, etc.) - and once you start talking using apps on a smartphone, you've multiplied the complications here 1000x. If you care that much, you probably should just give up on cell phones.

But, there are a tons of ways to make your usage of cell phones safer and more secure. The Guardian Project is a great place to start - https://guardianproject.info/apps/ - you can get their apps from the Play store, from the F-Droid OSS repo, or as APKs directly. It brings Tor to your Android, OTR chatting, end-to-end encrypted VOIP calls, and even PGP email.

iOS is a bit further behind with all of this, for various reasons.

There was a great guide on this last year, but the site seems to have gone offline. Some intrepid data-rescuers have put the content up on github:

https://github.com/opensafermobile/materials

Here's what GitHub says in their terms of service:

We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

That creates some interesting issues. When someone "forks" something, what rights do they have?

I suspect that many people not specifying a license for what they put on GitHub just assume GitHub owns everything.

I will also vote for The Old Reader.

I'm also contributing to the development of its notifier extension for Chrome, shaping it to be a more useful tool, in the spirit of "I have to live with that, may as well improve it".

Thanks! I'm trying to replicate as much as I can by July. I also have an Android client for it semi-working: angrroid

I can absolutly recommend NewsBlur!!

http://www.newsblur.com/

It's better than GoogleReader and is OpenSource. You've 3 options:
- use the free account (up to 64 sites)
- pay 24$/year for unlimited sites + extra features (fair price if you ask me)
- geek option: set it up yourself (you have all features in that way) -> https://github.com/samuelclay/NewsBlur.git

Plus, it comes with free iOS and Android-Apps.

I've set it up myself last week and said goodbye to google reader.

Try this alternative mobile interface:

https://github.com/mboinet/ttrss-mobile

In the very worst case, you can stand up your own server, as we have access to the source: https://github.com/samuelclay/NewsBlur

Well, I know this article is a couple years old, but it says you need two different database engines and an S3 account to make it work. If I'm standing up my own server with my own data backends, why would I want to pay for a third data backend?

I used Google Reader more than any other Google service. Which is why when they announced discontinuation, I decided to roll my own replica.

I have an instance of OwnCloud setup at home. I use it mostly for syncing contact and calendar data. I'm even subscribed to my girlfriends calendar and vice versa. The WebDav part I only really use as a quick way to get files from one device to another, and by device I mean smartphone, tablets as well as proper computers.

When Google announced the closure of Reader, OwnCloud started work on a news reader app too. I've been running it since the beta and I'm very happy.

Do you actually use a Mac? The red (X) one closes the window (also Command-W). Hiding (Command-H) is something different altogether and applies to the app as a whole. The yellow (-) button minimizes the window to the dock (Command-M). Neither of these two buttons are "arbitrary." They're both totally consistent. The green "Zoom" button (+) (no hotkey though of course you could assign one in System Preferences if you want) does as I described before - sizes the window to "optimal size."* This is the only one that may not seem entirely "consistent," in that it results in different window sizes for different apps; but that only follows logically from the fact that not every window needs to be the same size (ie. full screen or whatever). What is is the "optimal" size depends on the app's developers and the content being displayed. There is no reason a Finder window should take up full width on a 27" monitor (it would be 80% whitespace and unnecessarily block other windows) so the zoom button causes the window to size itself to fit it's contents and no more. Xcode, on the other hand, is designed to make use of all that width, so the zoom button will size the window to fill all the available space. There's nothing inconsistent about this - the underlying principle is the same in both instances, and the behavior is reliably repeatable in each app. For your purposes, I'd bind "Zoom" to some convenient hotkey and then you can easily fix Xcode's window size/position with a single keystroke when switching monitors (or try a window manager like Slate that can do this automatically when your monitor config changes; I don't think the one I mentioned before has that feature). * Older versions of iTunes being an exception; this button used to transform the iTunes window into the mini player. Thankfully they seem to have fixed that recently. Another 20 years of incremental improvements and maybe iTunes won't be an abomination anymore...

Yes I've used a Mac. I typed that post from a Mac. Sorry if I said the red button, I meant the yellow one. But you see that the app sizing its own window on that button is what makes it feel inconsistent. It may make sense to you, but its different than what Mac OS, Windows and x-windows based OSes were doing at the time that it was introduced (unless my memory is serving me incorrectly).

Do you actually use a Mac? The red (X) one closes the window (also Command-W). Hiding (Command-H) is something different altogether and applies to the app as a whole. The yellow (-) button minimizes the window to the dock (Command-M). Neither of these two buttons are "arbitrary." They're both totally consistent.

The green "Zoom" button (+) (no hotkey though of course you could assign one in System Preferences if you want) does as I described before - sizes the window to "optimal size."* This is the only one that may not seem entirely "consistent," in that it results in different window sizes for different apps; but that only follows logically from the fact that not every window needs to be the same size (ie. full screen or whatever). What is is the "optimal" size depends on the app's developers and the content being displayed. There is no reason a Finder window should take up full width on a 27" monitor (it would be 80% whitespace and unnecessarily block other windows) so the zoom button causes the window to size itself to fit it's contents and no more. Xcode, on the other hand, is designed to make use of all that width, so the zoom button will size the window to fill all the available space. There's nothing inconsistent about this - the underlying principle is the same in both instances, and the behavior is reliably repeatable in each app.

For your purposes, I'd bind "Zoom" to some convenient hotkey and then you can easily fix Xcode's window size/position with a single keystroke when switching monitors (or try a window manager like Slate that can do this automatically when your monitor config changes; I don't think the one I mentioned before has that feature).

* Older versions of iTunes being an exception; this button used to transform the iTunes window into the mini player. Thankfully they seem to have fixed that recently. Another 20 years of incremental improvements and maybe iTunes won't be an abomination anymore...

Citizen... all patriotic coders will add THIS fine backdoor^k^k^kpanel to their websites.

I've never heard of AmiPro, but I'd be surprised if any Windows 3.1 program (that wasn't driver-dependent) didn't run perfectly under Wine. Definitely worth a shot I'd say.

As for hardware and software support... when was the last time you called up Microsoft and they actually were able to help you solve your problem? I'm sure it happens on occasion, but every time I've reported a problem in their software (such as a ViewMaster monitor which was always detected incorrectly by Windows XP as a TV upon boot and made the screen low-res and all green), Microsoft's never done squat to fix it.

Contrast that to GNU/Linux. I ordered a Bryton GPS cycling computer, and assumed it would support GNU/Linux. It didn't, my bad. Fortunately, I found somebody who wrote a driver for a similar model. I gave them the specs of what I had, and they whipped up some driver modifications to get my device working perfectly - just to help a brother out.

Somebody got LightRoom working under a patched version of Wine and shared the details. If you upgrade to a new version of Windows 3 years down the road and LightRoom stops working, do you really expect Microsoft or Adobe to support you? I be the Wine community would. There is support, and then there is support.

You get my point.

https://github.com/MisterTea/MAMEHub/issues/3

We need help on this! We are having problems getting it to work on slow rPis so we can play online!

Not mentioned in the summary is a useful open source library to convert GPIO button presses to USB keyboard commands for the emulators. It uses minimal system resources, which is always good when working with the Raspberry Pi. You should be able to easily modify it to support more than the joystick and two buttons. https://github.com/adafruit/Adafruit-Retrogame

If you need to do some more massive JavaScript/DOM manipulation and querying then calling getElementByID and the others repeatedly will lead to extremely long code. It will also lead to unmaintainable code if you just put everything in one big code block. To keep your code short and to enable easy reuse, you'll need to encapsulate this code into functions.

You do realize all of that applies when you use jQuery as well, right?

Maybe you don't...

. Once you start making functions whose purpose it is to manipulate the DOM in a similar way across many different browsers, you are better off going with jQuery.

In the context you're trying to support the use of jQuery, it very obviously offers you no benefits what-so-ever. But you know that, right?

Well, I can't blame you for trying to make such a non-argument. It's VERY difficult to defend the use of jQuery. See, what this all boils down to is that you're comfortable with jQuery, not so comfortable with JavaScript, and already know that jQuery has long outlived any utility that it may have had in the past. You don't want to see your favorite "tool" die, so you feel the need to protect it from reality.

jQuery has promised, but never safely delivered cross-browser support. With 2.0, it gave up on that goal entirely. Besides, once you drop support for IE6, there's very little you need to do to maintain cross-browser compatibility. So little, in fact, that using jQuery actually *increases* the amount of work you need to do as you get to deal with cross-browser problems in jQuery and cross-jQuery problems with your plugins!

Recently, I decided it was (long past) time to upgrade so I reviewed our code, upgraded jQuery little by little, fixing things as they broke

For some reason, you mentioned writing reusable functions as a benefit of using jQuery. Using jQuery guarantees that your code will not be reusable. Sure, you can refuse to upgrade and artificially extend the life of your code, but you'll inevitably end up maintaining multiple jQuery versions, eventually loading multiple versions of jQuery on the same page! (If you use a lot of plugins, things will go to hell even faster...)

Think I'm joking? It's such a common problem that jQuery includes features to help you cope with it's instability (see: noConflict). There are a host of tools (like jQuery Quarantine) to help you manage the hell that you created because you swallowed a load of nonsense about a crummy library back in 2006. Er, sorry, read that as "thought you could save some time by using a popular library."

You could wind up essentially rewriting it, but chances are it won't be shorter/more efficient.

That's just absurd. jQuery primarily consists of functions that are common across browsers, wrapped in an incredibly inefficient library. It's primary (and only useful) feature was its selector engine, but that hasn't been an advantage for a very long time now. Once you learn more about JavaScript and the DOM, you'll realize how little jQuery actually offers you.

This is all off-topic. My original point was that jQuery Mobile is best avoided as it's too slow. (No surprise, no one is willing to defend THAT mess!) This turned in to "defend jQuery against the unbelievers!" thread, which I'm rapidly losing interest in.

https://github.com/BryanLunduke/

It is available on GitHub. Take it or leave it.

Yes they have since changed the license. But the point is that this is no different than any other dual licensing scheme. The license [1] is GPLv3. The only thing they've added is a linking exception for two libraries they require which is not compatible with GPLv3, OpenSSL and ATL. As far as I can see there's nothing else added or removed from the license which would make this any different than any other GPLv3 project.

[1] https://github.com/runrev/livecode/blob/master/LICENSE

This looks like fun.

Is there an open source version of this?

https://github.com/BryanLunduke/Linux-Tycoon

Yes.

Counter-point: Linux (kernel) hasn't forked significantly yet, despite Jeff V. Merkey's threats, and Linus certainly has incompatibility with more than a few devs.

Counter-counter-point: One of those incompatibilities result in the kernel folks forking the close-to-the-kernel udev, creating projects like eudev and mdev.

Counter-point: Linux (kernel) hasn't forked significantly yet, despite Jeff V. Merkey's threats, and Linus certainly has incompatibility with more than a few devs.

Counter-counter-point: One of those incompatibilities result in the kernel folks forking the close-to-the-kernel udev, creating projects like eudev and mdev.

I was going to suggest that too.

Turn the problem on its head. Instead of supplying them with an actual virtual sandbox to play in (lots of work) - give them the ability to spin up a bunch of different virtual network/server configurations on their own machines.

Vagrant configs can specify multiple servers and networks etc.

They can easily be blown away and rebuilt, they can start sharing their own custom environments.

BTW: checkout salty vagrant. Salt is a Python based configuration management tool like Chef and Puppet but much simpler and lighter weight. And because you're teaching them Python and most Linux distros already have Python builtin, you don't need to install much else to bootstrap it.

I'm sick of the cloud too, so I've installed this Firefox addon (Chrome one available also) that makes my life a bit easier when reading about the cloud.

I don't trust those figures at all; First of all I can also pull a result of 86.0 and 62.3 for the RPi (which is it?). Secondly in the same source as the Celeron result there is also a 3 ghz Xeon that only gets a score of 160.8. I can find an 866mhz PIII that scores 198, which given that's almost 4x faster than your quoted result for an 800mhz Celeron (and faster even than a 3ghz Xeon) makes the figures you're using seem suspect.

Github did this recently too which was annoying, because it was useful. They're not entirely clear why ... "confusing" doesn't seem nearly as likely as "abuse", though I am not aware of any abuse in particular. Since Google is providing Drive as an alternative, and not even immediately removing the service for those using it, it's not even as bad as Github's move, which removed it for everyone. I suppose it's an opportunity to cut another Google dependency though if you really want.

Sometimes the type system gives more overhead than safety. A wonderful satirical example in Java: https://github.com/Mikkeren/FizzBuzzEnterpriseEdition

You also have to weigh developer feedback time. I've developed web applications with Java Struts, coding directly to the Java Servlet API, Play Framework 1.x, and Play Framework 2.x (in Java, not Scala), and Python with Twistd. In order of speed of development of correct (i.e. in production without known bugs) code, they are from fastest to slowest: Python with Twistd, Play 1.x, Play Framework 2.x, Java with the Servlet API, Java Struts. Play Framework 1.x and Python give you instant reload. You save your changes, hit F5 in your browser, and see your change immediately. Anything I built without that takes three times as long. Play Framework 2.x doesn't have it, because under the hood Play 2 uses Scala and at least on my machine, best-case-scenario a Scala recompile of modified files after I change some Java file takes 5+ seconds. With Struts and just using the Servlet API, I have to reload the damn application and that's 10 seconds or longer. It seems like a trivial thing, but it's huge.

I'd say hot reload brings Java on par with Python for development, except Python has one extra feature: the REPL. "How does X work?" type.. "Oh, that's how it works", go back to coding. With Java, even in an IDE it's "create a public static void main (String [] args) throws Exception { /* actual code I want to test */ } " and either put Imports at the top or use fully qualified package names. So the equivalent "fast try something out" I do with Python still takes four times as long.

There's a reason that Google and Facebook and Twitter all use C++ and Java behind the scenes. But there's also a reason millions of sites use PHP, Python, Ruby, and Perl up front - because the development speed is so fast that you're into your testing (and unit tests) in a third the time of the Java version. So if your Java build takes three weeks of coding the application and one week of coding the tests, and your scripting language version takes one week of coding the application and two weeks of coding the tests (to offset the weaker type system), you still get to market faster with the scripting language.

Maybe the ideal is something like Perl6 (which has optional typing but does enforce type constraints when they're listed) or Groovy (which you can convert to Java more or less as-is once your rapid development phase is over).

Most of them, in theory.

Apparently the real reason to include Big Integers was to make it an attractive language for dollars and cents... for instance this commit came from financeCoding/master.

Exciting stuff...

The Pash project, an open-source reimplementation of Powershell, was recently resurrected: https://github.com/Pash-Project/Pash.

Nudge, nudge - you already can.

https://github.com/rg3/youtube-dl

I feel like you don't actually know anything about the platform. You're merely commenting on the way they're marketed, which happens to be ineffective on you.

  * All Chromebooks have local (encrypted) disk.
  * Chromebooks ship with offline apps written by Google for their Apps stuff (GMail, Calendar, documents, spreadsheets).
      + http://support.google.com/drive/bin/answer.py?hl=en&answer=2375012 explains how to set it up. You might have to click, *gasp*, twice.
      + GMail and Documents are writeable. Calendar and Spreadsheets are read-only.
  * The apps are written in the open HTML5 API. Anyone can write more offline apps, or games, or whatever. It's a fully-legitimate development environment.
  * If you want a full Linux, just install Crouton which gives you an Ubuntu chroot on both intel and arm chromebooks, under the auto-updated ChromeOS kernel and with disk encryption.
  * You can run Windows under VMWare, KVM, etc., on the samsung 550 and pixel, but it's somewhat painful on the 550 because you have to go through a challenging hack to turn on vmx. oops. (it involves soldering.)

AFAICT this is a well-supported Linux laptop, at last. If you don't like logging in through Google, that's a valid thing to complain about, but this "wah, wah, where are my apps" stuff is the same refrain we have every time someone offers a truly new operating system, "how do I run my old DOS programs on Windows," "how do I run my Windows personal organizer crapplet on my Mac," "Linux isn't ready for The Desktop because omg no apps." This short-term entitled-consumer view is like a default argument: "As a technology pundit, I'd like you to consider my well-informed view on the merits and faults of this new software platform, which is: I don't like it because it's not the incumbent."

What I don't understand, is where were all these whingeing douches when the "pads" came out? It wasn't, "it costs twice as much as a reasonable laptop, but more importantly doesn't run the $2000 of software I've already bought and on which my livelihood depends." Instead it was, "It's life-changing and almost perfect. We need to lobby $corporate_overlords to get the Creative Suite on this 1/5-power-CPU, 1/10th-power-GPU, under-ram'd, slow-SSD'd, external-storage-incompatible, overpriced Pad. Then it will be perfect! I can compensate for all the missing things with dongles and accessories! It's amazing!" You guys are really useless hypocrites.

so, get to work, and write some HTML5 apps: they'll run offline not only on ChromeOS but on other browsers, too. Compared to earlier apps, they're somewhat isolated from one another. Compared to earlier platforms, updates are faster and less quirky, security is much better, performance is similar on average but more graceful under memory pressure.

Or install Crouton. Or get a more expensive chromebook and run VM's. Or don't get one for yourself at all---get one for someone whose computer is always infected with spyware who is constantly nagging you for help. Or get one as an "extra" computer instead of these ridiculous "pads". Or don't get one at all.

But don't just watch an advert and then start blabbing about like some wise technical authority. I don't hang out with people because I want to pretend I'm part of a focus group all the time.

Tracking tickets: iD@GitHub, EFF-HTTPS Everywhere@Tor

and don't forget the excellent EnhanceIO, https://github.com/stec-inc/EnhanceIO. This allows you to add cache to any device on the fly without and pre-formatting. For the storage tiering inclined people, similar performance gains can be made with btier, http://www.lessfs.com/. Mark from lessfs also has a great deduplication project as well called...well... lessfs.

So the guy is lying? Perhaps. Or just exaggerating. But I doubt there isn't more than one data center for this very purpose. The question is what kind of hardware would be necessary to compress all the data live.

Ugh, you just store it compressed with LZO. The bigger challenge isn't storing it, it's storing it securely and secure from inside threats, that's the challenge. The cryptography involved, and technology to operate natively on cipher streams is where the actually interesting stuff is done. Storage alone is trivial.

Exactly. This isn't a major, it's a class at most. I'm a Mechanical engineer and took a few CS classes as electives.I was the only one in my class of CS majors that would unit test. I wrote script upon script to beat my projects to death. Consequently I also managed to get one of the highest grades in the class. This was back in 2003 when "CS" meant "I like computers" but there were numerous people in my class that would turn in half assed work.

Even at work where I use Matlab I try to test every single scenario possible in my scripts. Especially the stuff that I put on Matlab File Exchange, for example: https://github.com/jedediahfrey/matlab_saveppt2/blob/master/Test_SavePPT2.m

Source code is available here:
https://github.com/wikireader

Because Android has a cost

And FXOS is mostly Android

While Tizen,webOS are not available anywhere.

False and false

with the amount of Android code in FXOS its basically just Dalvik that's missing and you believe that javascript apps are going to perform better than native or java Android apps?

For the first time the capabilities of HTML5 and the open Web have been fully leveraged to create an entirely new mobile platform.

where have i heard that before? oh right, in web os!

What was just a toy project for Mozilla found a powerful client with a lot of money and market muscle to push the operating system.

microsoft has even more yet they've failed to gain traction. it's stupidity to believe that money and marketing is going to help a non-starter project with no tangible benefit to customers to succeed in the market.

this is a bit offtopic, but I can't resist linking another interesting release
https://github.com/exaexa/codecrypt

Actually, CSS3+HTML5 is Turing complete. Some madman implemented Rule 110 in it.

The rest of your post is correct.