Slashdot Mirror

Actually, there are several ports of MilkDrop available: projectM is MilkDrop for Android and iOS – http://projectm.sourceforge.net/ milkshake is MilkDrop for the browser – https://github.com/gattis/milkshake You also might to check out this JavaScript port of AVS, another visualizer that came with the Winamp installer – https://github.com/azeem/webvs

Intel x87 scalar FP instructions use an 80 bit internal format for higher precision. Intel SSE2 vector FP instructions use 64 bits. You will see last bit variations depending on which instructions the compiler chooses.

And the compiler may choose differently depending on whether it's compiling for 32-bit or 64-bit x86.

You can also do exactly what Node does in Lua using the actual underlying C library that Node uses with this (for those who prefer callbacks to coroutines but still prefer Lua).

Did you look at the released code?

http://www.glitchthegame.com/public-domain-game-art/

Serverside code:

https://github.com/tinyspeck/glitch-GameServerJS

Is it complete? I don't know of anyone who has tried to find out.

https://github.com/tinyspeck/glitch-GameServerJS

You're welcome.

I believe what you're looking for is here: https://github.com/adafruit/Adafruit-Raspberry-Pi-Python-Code

Most of their code is on github, https://github.com/adafruit . Did you not find it there?

TFS makes it sounds like it's a long article about how Linux Mint is insecure.

Here's the entirety of his commentary:

Do you think that Linux Mint is a vulnerable system ? Really ?

https://github.com/linuxmint/mintupdate/blob/master/usr/lib/linuxmint/mintUpdate/rules

this is the list of packages it will never update, instead of just
integrating changes properly with the packagaes in the ubuntu archive
they instead suppress doing (security) updates at all for them.

i would say forcefully keeping a vulnerable kernel browser or xorg in
place instead of allowing the provided security updates to be installer
makes it a vulnerable system, yes

i personally wouldn't do online banking with it ;)

ciao
        oli

The fact that there are significant reverse-engineering efforts going on
https://github.com/raspberrypi/firmware/wiki
https://github.com/hermanhermitage/videocoreiv/
is proof that the Broadcom chip in the Raspberry Pi is anything but open.

Have you realised that you posted the official raspberry pi foundation github account as a reverse engineering proof? They are doing many things, but reverse engineering is not one of them.

Also, I don't think anybody needs proof. It is common knowledge...

TI fully documents their system on chip (SOC) chips.

Sure. Could you please send us a reference of the SGX530 which is the GPU in beagleboard? And the kernel drivers that interface with the blob doesn't count, obviously.

I mean, I like a good argument, but pleeease try to check your facts first.

The fact that there are significant reverse-engineering efforts going on
https://github.com/raspberrypi/firmware/wiki
https://github.com/hermanhermitage/videocoreiv/
is proof that the Broadcom chip in the Raspberry Pi is anything but open.

Have you realised that you posted the official raspberry pi foundation github account as a reverse engineering proof? They are doing many things, but reverse engineering is not one of them.

Also, I don't think anybody needs proof. It is common knowledge...

TI fully documents their system on chip (SOC) chips.

Sure. Could you please send us a reference of the SGX530 which is the GPU in beagleboard? And the kernel drivers that interface with the blob doesn't count, obviously.

I mean, I like a good argument, but pleeease try to check your facts first.

EnchanceIO is an alternate ssd caching solution for linux. It's a kernel module that can be setup against any existing FS and can be attached/removed even whilst the FS is mounted. Supports writeback/writethrough and a bunch of cache replacement algorithms.

Well, I used teh google and found out that it's a commercial product but that it's also open source. Actually, it's Free Software, apparently GPLv2.

So what I get from this is that this is basically dm-cache as a module. Yes? Hmm, either I need to install more deps, or this isn't going to work on 3.11

EnchanceIO is an alternate ssd caching solution for linux. It's a kernel module that can be setup against any existing FS and can be attached/removed even whilst the FS is mounted. Supports writeback/writethrough and a bunch of cache replacement algorithms.

Well, I used teh google and found out that it's a commercial product but that it's also open source. Actually, it's Free Software, apparently GPLv2.

So what I get from this is that this is basically dm-cache as a module. Yes? Hmm, either I need to install more deps, or this isn't going to work on 3.11

I have this installed, and it keeps separate track of BOTH wifi measurements and cellular network measurements.
But it measures both, and allows you to swipe left and right to see each measurement it took.

What I've learned: My carrier is pretty pathetic.

Note
Being Open source, you can see exactly what is being reported, but I predict that won't stop the tinfoil hat crowd from claiming the binary does not reflect the source code.

Everybody in the know has already migrated to a GitHub.
At this point, hosting a project on SourceForge just seems quaint.

Oh, I didn't realize you were the author of jor1k! It's amazing. Congratulations! I also didn't realize it was completely hand-written, rather than cross-compiled to asm.js. That is impressive.

It definitely seems like you've gained a lot of speed by hand-coding the emulator. Have you seen jsbochs? I'd be curious to test it against the Virtual x86 you linked to.

I have in my wiki a site describing the speed problems and how I solved them. https://github.com/s-macke/jor1k/wiki/Technical-details
I am not doing any memory allocation during the emulation.Everything is done at the beginning.
Debugging is a real issue. I used mainly console.log. But Firefox and Chome provide some debugging features.

It's possible to compile bochs to Javascript using Emscripten, so it's only a matter of time. If you do get Crisis running, let us know what kind of framerate you're getting. :)

I know. But to build an OpenRISC (1000-2000 lines for the core) emulation is much more easy than to build an x86 emulation (10000-20000 lines for the core). And I would not use the closed source emulator by Fabrice Bellard. Try this new emulator from: http://copy.sh/v24/ This seems to be a much better base for development.
I have also made a list of online emulators currently available. https://github.com/s-macke/jor1k/wiki/Similar-emulators-written-in-Javascript
Emscripten is boring. It uses no emulation. ;)

Wesockets do allow connections to any server. It's also working from this site: http://s-macke.github.com/jor1k/

No need—it has already been done.

If it's linux in the internals then the source can be found here: https://github.com/torvalds/linux/blob/master/drivers/usb/class/usblp.c#L347

It's just a small change!

It may be a bit of an ad, but they are fairly well known in the mobile world as a very successful startup. They have also contributed a ton of open-source libraries https://github.com/square

I use Github Releases.

You could also use Internet Archive, which offers unlimited file storage and bandwidth. Yes, you can use them for this.

Got a 404 when attempting to access the source code on GitHub. https://github.com/CMSgov/healthcare.gov

After six months, zero progress on fixing it.

According to the bug, it was fixed in an upstream pull request yesterday. Given the usual rate at which upstream pdf.js updates are landed for downstream Firefox, it's very likely the fix will be in Firefox 28. Of course, you can confirm it's fixed in a development build of pdf.js whenever you want: https://github.com/mozilla/pdf.js#browser-extensions

After six months, zero progress on fixing it.

According to the bug, it was fixed in an upstream pull request yesterday. Given the usual rate at which upstream pdf.js updates are landed for downstream Firefox, it's very likely the fix will be in Firefox 28. Of course, you can confirm it's fixed in a development build of pdf.js whenever you want: https://github.com/mozilla/pdf.js#browser-extensions

https://github.com/djrbliss/rose-exploit

You could also use the X-Label header like I did with a IMAP proxy I wrote for Gmail.

Another way of doing things is notmuch.

I probably got in early enough to grab the code before they go slashdotted. Looks like it's also on github, here:

https://github.com/xiw/stack

My guess is that they're distributing the binary and paying the fees associated with its distribution. The source code is coming: https://github.com/cisco/openh264 but it's only useful to tick the "open source" checkbox. The important thing is that they're paying the fees and that the binary module is under a BSD license.

This year had been a lot of noise regarding linux containers, and this book seem be not aware of them or how they could change the landscape. Docker gained a lot of steam, and a lot of cloud service providers are adopting it (part of the magic is not just being based on LXC containers, but also combining it with aufs to make some sort of inheritance between containers). Also there are some newcomers like lmctfy, the recently released open source version of the google containers technology, or warden from cloudfoundry that could be another approach

This year had been a lot of noise regarding linux containers, and this book seem be not aware of them or how they could change the landscape. Docker gained a lot of steam, and a lot of cloud service providers are adopting it (part of the magic is not just being based on LXC containers, but also combining it with aufs to make some sort of inheritance between containers). Also there are some newcomers like lmctfy, the recently released open source version of the google containers technology, or warden from cloudfoundry that could be another approach

If Audacity is becoming too limited, perhaps you

1. Need more multitrack features (Audacity is more an editing tool than a mixing one)

2. Need a DSP (Digital Signal Processing) package so you can create your own audio processing patches

As Audacity uses LADSPA plugins, you'll have the same ones in Ardour and any other DAW (Digital Audio Workstation) software. Another DAW would give you other analysis and another UI, but unless it goes beyond LADSPA/LV2, you'll have the same audio processing plugins. A "next step" here would be working with audio directly by programming, designing synthesis models, filters and so on. Usually that's not easy, but that's what many contemporary music composers do all the time.

For the asked "good audio processing/editing/enhancing setup that can run on different platforms", I suggest you try AudioLazy (https://github.com/danilobellini/audiolazy) as part of this setup. It's an open source DSP for Python. Functions like "lowpass", "highpass", "resonator" gives you some common linear filters, and you can make your own [time variant] linear filter with the "z" object, besides basic operations (e.g. multiplying signals), synthesis (ADSR model, table lookup, FM synthesis, etc.), non-linear processing (e.g. getting the "arctan" of a signal to distort it), etc..

I prefer replacing them with "my butt". Which is what I'm doing, already, so this thread is a goldmine. It makes your post nonsense, though - I'm not sure why I would replace your butt with someone else's computer.

I think you're right about the importance of individual players, but the overall trend is unstoppable. Google, Apple, Microsoft, Yahoo and Mozilla all want JS to take over for different reasons. In contrast, none of those companies care about client-side Java, and some actively hate it.

I do think it's a bummer for groups with a lot of legacy Java. I wonder if it's possible to go from Java -> LLVM -> JS, using VMKit and Emscripten as starting points. Obviously it would be quite a process, but it could be less work than scrapping millions of lines of code.

Visdom and the backend source code have been on Github for a while now: If Battelle was really convinced that Corey stole the code, you’d think they would just look there first. No need for subpoenas ref

You might have a point if that were the only basis for the decision. The basis of the restraining order was to prevent irreparable harm based on likelihood to succeed with a claim, and that case was well made.

Here's the judge's info, it's right at the bottom of the court order where someone who read it would expect to find it, next to his signature. I doubt it will have the effect you wanted, because this is a decent decision.

B. Lynn Winmill
Chief Judge
United States District Court

The only real counterargument would be to point to https://github.com/visdom/ which has the open source version, and was registered July of this year. Surely they could just look at the code and see if there was infringement? No, the evidence on the hard drive will be captured and stored pending further developments in the trial. The Court was preserving evidence which would most likely show that any copying was more than incidental.

This was the unquestionably correct decision, and the slashdot headline and summary are woefully oversimplifying in order to cash in on outrage. I hope you have disabled advertising, because Dice should be embarrassed that shit like this end up on the front page, and should certainly not profit from page views.

Direct quotes from the decision follow. Note: this guy worked at the company he is accused of copying from, so access to the original Sophia code is not in question, only whether it was used as a reference.

As for infringement, if there is no evidence of direct copying, âoeproof of infringement involves fact-based showings that the defendant had âaccessâ(TM) to the plaintiff's work and that the two works are âsubstantially similar.â(TM)â Funky Films, Inc. v.Time Warner Entmâ(TM)t Co., 462 F.3d 1072, 1076 (9th Cir. 2006) (citation omitted).

Here, Battelle has put forward adequate circumstantial evidence to permit an inference that defendants copied Sophia. Battelle says Thuen created Visdom in a time period that is impossible without copying; he described Visdom in nearly identical language as was used to describe Sophia; he used the same demonstration videos toshowscase Visdomâ(TM)s functionality as he did to showcase Sophia; he has admitted to copying parts of Sophia; and he has adopted a nearly identical name. Based on this record, the Court concludes that Battelle is likely to prevail on its copyright infringement claim.

...Additionally, the facts show that Thuen previously defied Battelleâ(TM)s instructions to refrain from widely releasing video demonstrations of Sophia on the internet.

...To support this assertion, defendants cite Battelle employee Michael Colson, who testifies as follows: I have 23 years of experience as an investigator for government and private entities and have worked many times on matters where employees have â" without authorization â" taken data from employers for their own purposes. In my experience it is very common for such individuals to simply delete the data when they are confronted with aninvestigation, rather than admit wrongdoing. This is particularly so inregards to those with technical skills to wipe the data in a way which does [not] leave digital footprints. My investigation has revealed that Thuen has (or had) an unauthorized copy of executable Sophia code on his home computer and, from my experience, there is a high risk that he might wipe his computers destroying evidence if he had advance warning.

The new company he works for actually released it already. It's been on github for the last 7 months. If there was a question of ownership on the code, why it couldn't be figured out from comparing the released version of Visdom to the internal version of Sophia to see if any code was stolen is left up to the reader.

At one point I found myself composing some email (started with notes for a conference, then code-heavy email) in Github's editor, rendering, and then pasting into an email. And then I realized that I'm a programmer and can make stuff to do stuff. So I made Markdown Here (or the project page on Github). It's a Chrome/Firefox/Safari/Opera/Thunderbird/Postbox extension that allows you to write email in your normal email editor, but in Markdown, and then render it before sending. It also supports syntax highlighting and some TeX math support. And it works in Google Groups posts, Evernote (web interface) notes, Blogger posts, and so on -- anywhere that uses contentEditable or designMode for the editor (including TinyMCE-based and CKEditor-based ones).

So, yeah, I use Markdown for email. There are about 15,000 Markdown Here users, so I guess they're part of the answer too.

If you're marking up arbitrary prewritten text, then yes, I agree. But if you mark up as you write, then Markdown really does save you a ton of time. You can try out new headings, split paragraphs, etc—without worrying about balancing tags.

It's really intended to be a writing aid, not a markup or styling tool. I've been writing HTML since 1994 and swear by Markdown—so much so that I ported it to Objective C. I use InDesign to layout print materials, but I would never write directly in it.

For writing on the Mac, I swear by Mou.

Could you elaborate a bit on this? I had the impression that D-Wave's users had to map their problem to fit what D-Wave computes, not the other way around. That would make comparisons with a specialized software solver appropriate, wouldn't it?

The blog post in question also includes a link to the source code of the specialized solver (Prog-QAP), and others have confirmed that it produces the same results as CPLEX, the general solver that D-Wave beat.

CPLEX is indeed slower than D-Wave, though newer versions have brought the factor down from 3600x to 14x. But again, CPLEX is a general solver, while D-wave is specialized hardware. The specialized software solver Prog-QAP is *much* faster than CPLEX, and gets a 12000x speedup over D-Wave when running on a single core.

But all of that is a bit old, and it may be that D-Wave has produced more impressive results after that. I hope D-Wave's approach results in something able to beat classical computers, even if it doesn't lead to a general quantum computer. But I really dislike all the secrecy they employed - that is not how science is supposed to work. The fraud speculations they have had to endure are entierly self-inflicted due to this secrecy.

I've really only seen people getting serious about writing libraries for C++ in the last decade or so. Boost has come a fantastically long way in that time and adds most of the stuff that the newfangled C++ STL was lacking. In fact, they added a lot of the Boost stuff I've been using to the C++11 spec, pretty much verbatim. I can pretty much change a header include from to the new C standard thing, change the namespace from boost:: to std:: and not change any other code and it'll work. I was actually stunned they kept the thread syntax the way boost did it.

No matter what you're trying to do or the programming paradigm you're trying to do it in, you will never be able to just crap out some code without thinking about its design and what you're trying to accomplish. When people think of the difficulty of programming, that's where the hard part is. Learning a language is easy. Learning to express your instructions to the computer in a way that's maintainable, efficient and reasonably bug-free... that's not so easy. I've seen many companies through the years constrained by the design of their in-house software. Once the business starts changing to meet the demands of its software, you start having problems. "We can't do that because our software won't allow it," is a huge drag on a company. You start losing opportunities not because something is not possible but because something is not possible with the tools you have.

A lot of the programming fads (OO, Functional, Ruby) imply that you can just start crapping out code without thinking much on what you're trying to accomplish. Buying in to that hype is foolish, and potentially damaging to your business. Some of the fads actually do make it easier to write reusable and maintainable code (OO and test-first come to mind, though I haven't drunk enough of the test-first kool-aid to actually write the unit test first. I usually don't wait much longer than the object I'm testing being "mostly done" to write a test for it, though.

A modern library implementing dataflow programming is: https://rx.codeplex.com/

The relationship between the actor model and flow based programming is discussed here: http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussion

Personally i like using f# with rx using this wrapper: https://github.com/fsharp/FSharp.Reactive

I see FBP as a generalized form of functional programming where you can, and have to, specify how the expressions are put together temporally.
It gives you the advantage of automatic (in rx you have to specify the scheduler) concurrency but is cumbersome for stuff that is easily expressed in a synchron way (List processing...).
I guess you would want the most coarse grained granularity.

A nice book on FBP is: http://www.jpaulmorrison.com/fbp/ (the first edition is freely available)

As for the idea that FBP is coupled to visual programming and will enable non programmers to write complex programs, well:
Visual programming makes writing programs for easy problems even easier and for complex problems intractable.
And guess what: The easy problems were already easy to begin with!!!

Does the Intel FORTRAN compiler deliberately emit suboptimal code for non-Intel chips, like the Intel C Compiler does? If so, and if you have anyone using AMD chips, you can pick up more speed by patching the binary to never use the substandard code paths.

http://www.agner.org/optimize/blog/read.php?i=49

https://github.com/jimenezrick/patch-AuthenticAMD

Julia

Source code seems to be available online here. A quick look at the User Manual indicates that all communication is routed via tor which raises the bar for tracing connections significantly.

Source code seems to be available online here. A quick look at the User Manual indicates that all communication is routed via tor which raises the bar for tracing connections significantly.

Looks like with PGP & Tor, & USB Keys. It's detailed here. https://github.com/freedomofpress/securedrop/blob/master/docs/user_manual.md

Why bother audting a closed binary which can change drastically from one version to the next, requiring a near-complete (if not total) re-audit (a laborious process the first time around)?

The better solution is to look to open source implementations, like tcplay. Audit an open source implementation, where it's easy to see exactly what changed and how it might affect the machine's state.

This is a bad solution to a non-problem.

Given all of this, plus the problems with TrueCrypt authorship etc. I think the best course of action is replacing with a free implementation, maybe starting with something like this?

Ah, I see the current TrueCrypt license has undergone substantial changes since the early days. Looks like a complete mess to me :/