Slashdot Mirror

That kind of gateway?

You can get the single images from the camera and stitch with a third party tool if you like!

Such as Hugin.

You know it can be fixed in seconds right? http://sourceforge.net/projects/wgaremover/

Some bulky "management interface" to hold your hand while you take 10 times as long as necessary to do the simple task of *removing an entry from a text file*? What is wrong with you?

That sounds great and wonderful until you try to configure something like SS5 and realize just how arcane and difficult doing config by hand can be at times.

Not that I generally disagree with the premise, I just think your lenses are perhaps a bit too rose-tinted; there are a lot of programs where getting the text config just right is a nightmare.

It looks like they didn't want to provide a BIOS bootable image at this time. Whether they will do that in the future, who knows.

Regardless, I'm sure there's already BIOS supported images out there as it's not difficult to make a usb drive bootable and install grub on it. You could even do it in Windows.

If you liked Marathon... it lives on.

Or you can always grab a System 7.5 image and set up Basilisk II (amusingly enough, you can pretend to be a Quadra with a 1920x1080 graphics card... the experience is pretty surreal).

Let me google that for you:
Wikipedia page on Hardware RNGs
Wikipedia list of Hardware RNGs for sale
Raspberry Pi has hardware RNG built-in
Don't trust manufacturers? Build your own!
Here's how HotBits did it
LavaRnd uses your lens-capped webcam to generate random numbers
Once you have it, make sure you test it!

Sorry for the snark, it just makes me sad to see a post get modded to +5 for asking a question that's long since been answered, on this site, even.

http://deduced.sourceforge.net/

I liked the amount of functionality I could get in just a few lines of code. Even the user interface was generated by reactive rules.

The thing that puzzled me the most with this tool is the lukewarm reaction of most developers who looked at it even when I proved that it could do things in about 10 times less code than a typical OOP solution.

Instead of writing your own scripts, perhaps you can try http://md5deep.sourceforge.net/

Snapraid (free!) might be an option: http://snapraid.sourceforge.net/

It snapshots your data to some parity files on a separate drive. All you would have to do is occasionally copy those files offsite. Snapraid includes commands that allows you to check and fix bitrot as well.

Or use sha1deep from the md5deep package. It's made specifically for hashing and comparing file trees and has heaps of behavior-modifying options.

Foobar2000. The only piece of software I really miss after moving to Linux.

If you miss Foobar, try deadbeef. It's not as configurable, but it's a solid little player that will look very familiar to you :)

I remember experimenting with a C++ framework that would work somewhat similar. Lazy evaluation and such. http://sourceforge.net/projects/ditto

MUCHO KUDOS FOR THE LINK, my man !

It was also supposed to have lazy/dynamic/late-binding expressions (i.e. lazy_int a = b + c;), but it turns out you only very rarely have any use for that type of expressions. At the time, there were also far superiour C++ frameworks being developed which could do these things as a side effect of supporting more useful programming models.

This RP thing doesn't really seem to do anything more than that.

Looks like this weekend I'll be fully occupied

I need to know more about all this !

Thanks again, man !!

I tested many, then went for Guayadeque http://sourceforge.net/projects/guayadeque/ and never looked back

I remember experimenting with a C++ framework that would work somewhat similar. Lazy evaluation and such. http://sourceforge.net/projects/ditto, it's long since been abandoned because, well... the only thing this way of programming solves is a small part of the "R" in "CRUD". It worked brilliantly for showing information on screen and automatically updating all kinds of stuff whenever some data changed, but in the end it only solved the least difficult part of creating an application, and doing so at a relatively high CPU% cost.

It was also supposed to have lazy/dynamic/late-binding expressions (i.e. lazy_int a = b + c;), but it turns out you only very rarely have any use for that type of expressions. At the time, there were also far superiour C++ frameworks being developed which could do these things as a side effect of supporting more useful programming models.

This RP thing doesn't really seem to do anything more than that.

Making high-quality music used to require investment. Expensive instruments at a minimum - but if you didn't want to sound like Kenny, you'd also need high quality microphones, sound damped recording studio, mixing desk, specialist technician to operate it and several high-end recorders capable of syncronised operation.

Actually, that's largely been a myth since the advent of consumer grade, multi-track tape recorders.

For instance, the Sublime album Robbin' The Hood was recorded exclusively on a 4-track tape machine, and it sounds awesome. The problem, however, comes in with mastering the tracks. Not sure how they managed it back in the early 1990's (I'm guessing they went to one of those expensive studios), but the solution today is as simple as downloading a free copy of REAPER and learning how to use it. If you don't mind spending a fair amount of cash, there's a plethora of other DAW options out there; I'm a fan of Logic myself.

Hell, I bet dedicated audiophiles could probably come up with studio quality stuff using nothing more complex than Audacity.

LOGO may teach concepts of building blocks and using them better, but all that was really covered (in my upbringing) was drawing shapes. Sometimes it was a robot turtle, which was kind of neat, but primarily a diversion.

At that age, the learning of concepts wasn't enough of it's own reward.

You're right about engaging reward mechanisms being an essential component too, but that's something for libraries and/or editor environment to provide. (e.g. Here's an Asteroids game written in FMSLogo.) Of course, you also need educators who can teach LOGO effectively and aren't just rote reading from some mindnumbingly tedious and creativity-killing "official teaching plan". The whole goal of LOGO is to drive self-motivated learning - the educator's job is simply to introduce concepts and techniques that aren't readily discoverable by themselves, such as the ability to define your own words (e.g. abstraction and procedures), at appropriate points in the student's learning curve.

LOGO major problem has always been a presentation one. It failed to explain its motives, techniques and goals to the decision makers in positions of influence and control, allowing itself to be categorized and pigeonholed as everything it was against. Instead of being seen as a tool for learning structured thinking and problem solving, it was viewed as a tool for "teaching programming". Instead of being seen as a highly scalable, open-ended language, it was viewed as a "toy language". Instead of being seen as an egalitarian platform welcoming all students of all abilities, it was pigeonholed as something "for technical kids only". Instead of being seen as a foundation that users could progressively build up in layers to form whatever vocabulary they need to express themselves, it was seen as incapable of anything more than pushing a turtle around the screen with crude FD and LT commands. Instead of being deployed a vehicle for self-education and growth, it was frequently shoehorned into standardized, rote "teaching" patterns guaranteed to destroy any child's early love of learning and exploration.

Now we have fashionable "post-LOGO" "kid-oriented" "teaching" languages like Scratch, which manage to take LOGO's key goals and toss them on the floor in an attempt to make themselves friendly and accessible to the GUI generation. Scratch looks easy because it is visual; LOGO looks hard because it's text. Yet appearances are deceptive: Scratch is really just a return to the old Algol way of endlessly banging rocks together - in trying to improve on LOGO it utterly misses the point of LOGO and undoes everything it tried to achieve. Rather than reward users for expanding its own primitive vocabulary into their own rich, powerful, tailored languages in which to efficiently express themselves, Scratch rewards them for mashing together ever longer and more convoluted chains of "Lego blocks". The best Scratch (or BASIC) programmer isn't the one who can express the most using the fewest number of words, it's the one who can make their chain the longest before burying themselves with insane levels of self-generated complexity.

As reward mechanisms go, Scratch's brightly colored pluggable blocks could hardly be worse. Programming isn't about the journey, it's about reaching the destination by the shortest, most effective route possible. Scratch's cheap gamification of the coding process, combined with its failure to promote abstraction as the fundamental building block, communicates the reverse, rewarding students for generating complexity instead of eliminating it. Scratch users, like BASIC users, are absolutely notorious for producing spaghetti.

The power of abstraction is in allowing users to manage their program's complexity, keeping it within limits they can effectively control, but you can't teach students how to do that if abstraction and procedures are fearf

I'd suggest attaching a different foot, but I don't know how mature that is. So I'll just name-drop the prosthetic I use on a Windows 8 PC at work: Classic Shell.

So how come the new hotness of the Windows video system is only as good as this apparently old and knackered XWindows system

Did the tests in question go through the X server, or were they rendering images by directly talking to the graphics hardware and largely bypassing the X server, using the X server mainly for 2D stuff?

You might try starting with: http://cratermatic.sourceforge.net/ (disclaimer... this was written by my son some years ago as a NASA intern). It is nothing like AI, but is a classical topography algorithm (basin filling).

Your son is the one who sent me the data :-)

The online project does not have the dataset, and the dataset links on that page are broken. After talking with your son a bit he agreed to send me the data.

Looking at the cratermatic results, I notice that the algorithm has problems with certain situations, mistakes that a human analyst wouldn't make(*). This is what piqued my interest in the project - what is it about the human algorithm that does so much better?

The recognition feature is relatively simple (circles or basins), so this dataset makes a much better meal for analysis than something more complex like "is there a dog in this picture?".

Thank your son for me. The data is a unique blend of simplicity (of feature), volume (lots of data), and clear standard for comparison (the cratermatic output). Everything a researcher could want.

(*) The algorithm seems to have problems(**) with intersecting craters, craters contained within craters, and partial craters (incomplete arc of lip visible). It detects many "tiny" irregular craters which seem at first glance to not be actual craters.

(**) This is against a background of many craters correctly recognized. The program is quite useful, I'm just wondering if there is a better technique

The problem is they have decided to shift control of application installation into firmware, not for the benefit of the consumer but to lock the consumer into their market place and severely limit competitive choice. Is likely to be very worthwhile to start driving in that wedge between Android and the annoying Goggle App store and start pushing for more FOSS applications on places like http://sourceforge.net/. People who buy unlocked phones expect them to be 'Unlocked' not not just partly unlocked.

PC owners for decades didn't need to be controlled by an app store and there is absolutely no reason smart phone user should except for greed of certain organisation seeking to pretend to be old world media publishers and seeking a cut for basically nothing other than an artificial anti-competitive barrier they purposefully created.

And yes, "OH THE HORROR" people have been updating hardware drivers (firmware) on PCs for decades. Ahh the FUD, the FUD, all to keep people looked into the kiddy pool app store.

Here is the torrent file mentioned in the summary:
http://xowa.sourceforge.net/torrent/wiki/en.wikipedia.org/Xowa_enwiki_2013-11-04_wiki_complete.torrent

... goes to http://xowa.sourceforge.net/

An open-source project that still uses SourceForge. How delightfully quaint.

On their homepage it has a news section at the top. As there are only 12 months in a year and their first date is 2013-11-25 I can only assume that they follow this date format consistently throughout their website so your date will be November.

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

Maybe you should read stuff from people who actually program:

http://www.utf8everywhere.org/

Here is some actual comments from boost developers:

http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/recommendations_and_myths.html

Here is an actual proposal to fix filenames on Windows by translating from UTF-8 (filenames on Windows are the *only* reason people use UTF-16, and Microsoft's refusal to allow the a api to handle UTF-8):

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3505.html

Long discussion with many points of view (including yours) but I hope this convinces you that there is disagreement with you:

http://programmers.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful

Here is somebody trying to patch boost to handle unicode by supporting UTF-8:

http://sourceforge.net/p/tinyxml/patches/54/

They did released Milkdrop under the BSD license a few years ago, there's a clone for OpenGL. XBMC uses it, and it can even load Milkdrop 1.x presets (totally just grabbed a huge set of those and am living like it's 2001 right now). I'm unaware of anything that can emulate AVS presets unfortunately.

Audacious can load Winamp 2.x and XMMS skins too. I'm still using it after a few years of flirting with other media players (ok, I may have given up and used xbmc on the teevee machine, but that's because it has a nice party mode and milkdrop!).

They did released Milkdrop under the BSD license a few years ago, there's a clone for OpenGL. XBMC uses it, and it can even load Milkdrop 1.x presets (totally just grabbed a huge set of those and am living like it's 2001 right now). I'm unaware of anything that can emulate AVS presets unfortunately.

Audacious can load Winamp 2.x and XMMS skins too. I'm still using it after a few years of flirting with other media players (ok, I may have given up and used xbmc on the teevee machine, but that's because it has a nice party mode and milkdrop!).

For even more cryptic reasons, AOL had (now deprecated, sometime in middle of the last decade) TOC and TOC2, which were different instant messaging protocols, used by some AIM client releases, and some other IM programs(Did you know that AOL once released an IM client written in Emacs LISP? I sure as hell didn't... Abandoned now, of course; but I had no idea that AOL would even hire you if you knew about stuff like that), that was architecturally distinct; but interacted with OSCAR.

Thanks to XMMS, Audacious and many other open-source projects, the Winamp legacy lives on!

I couldn't believe it when I installed some software from Sourceforge a while back and ended up with a malware toolbar in my browser

According to This; it is never done without the developer opting in.

In July 2013, we launched a pilot version of an opt-in revenue-sharing program called DevShare. DevShare is a partnership program offered to SourceForge developers to turn downloads into a source of revenue for them, by bundling their applications with third parties’ offers.

...

This is a 100% opt-in program for the developer, and we want to reassure you that we will NEVER bundle offers with any project without the developers consent. The DevShare program has been designed to be fully transparent.

Per the Sourceforge blog article:

Last but not least, we will only include projects that have opted into our program. Our compliance processes are very strict and, as such, our beta program is going to be invitation-only during this first phase. If you would like to participate in this revenue-sharing program, just drop us an email, we’ll be back to you as soon as possible.

[they] strongly encourage the top projects to use a new (closed source only) installer

SourceForge not only seems to have missed this key point but has completely reversed it's previous position on Open Source being a key component to transparency. Instead, SourceForge claims:

The DevShare program has been designed to be fully transparent. The installation flow has no deceptive steps...

Who says it has no deceptive steps? How do I audit the source code to the installation flow?

For anyone that reads the SourceForge blog, this seems to be a very jarring change in prospective on the part of SourceForge. Several previous SourceForge blog posts bring up transparency, but always in the context Open Source Software. Before November 2013, I can't find any SourceForge blog posts that refer to close source as "fully transparent." I also can't find any other SourceForge blog post that tries to claim close source software contain no deceptive steps. Once SourceForge is able to make the leap that a close source installer is fully transparent, there really is no common ground to continue a discussion on. It isn't a matter of a third party being a bad actor, SourceForge itself is the bad actor. This SourceForge blog post is proof of erosion taking place on fundamental ideal which where the foundation of SourceForge.

Or you could just use Freenet. It's slow, but it's specifically designed for anonymous, censorship-resistant file sharing, and since every node stores file chunks, every node will help the network even if run by a sick weirdo who's only interested in discussing the philosophy of ethics on Frost.

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've never used it myself but there is wxC. AFAIK it's mostly used as a base for the bindings to the other languages (like wxHaskell), but perhaps it is good enough to be used directly.

Hmmm, several posts, yet no mention of UDT so far. It would be nice if the benchmark included it.

Real Slackware users use a Desktop so they can run command line shells in six xterms simultaneously.

You only need a window manager (like Fluxbox, fvwm, xfwm, sawfish etc) to manage multiple xterms, not a full desktop environment.

And you don't need X11 at all, since tmux will allow you to do all of that from a text console.

eg.: http://tmux.sourceforge.net/tmux3.png

(it's not a dangerous bit of software)

First of all, what mythical Windows Ext2 filesystem driver are we talking about here? Last I checked, there wasn't one.

Are you talking about Ext2Fsd? The same one that lists Windows BSODs as a feature? Read the comments on sourceforge and then tell me this is something that Google would want to distribute.

The prevalent attitude seems to be 'The code is there for you to modify. Do it yourself.' For the average user, that could mean developing proficiency in some programming language, familiarity with that software's architecture before they even begin to understand how to get what they want.

Making matters worse...most open-source projects are severely under-documented. Even though the source is available, getting past the hurdle of severe under-documentation is too much of a hassle. It takes dedication to get to the point where one can contribute meaningfully to an open-source project, and not for any good reason — it shouldn't take that much effort.

Making matters even worse...in my experience, most open-source-project maintainers will resist documentation. I just went through this with an open-source project I've been interested in a long time. Since the source-code had practically no comments whatsoever, I took it upon myself to learn the subject matter (in this case, NOT an easy task), then learn large parts of the source code. Then, being the sort that's willing to contribute, I offered to document the code. The maintainer was willing, even eager, for it. Then I submitted my first patch...and he immediately changed his tune. He found my documentation to be "excessive", and quoted chapter 8 of the Linux kernel coding guidelines to bolster his case. Frankly, I couldn't disagree more with his viewpoint.

I'll never understand, for the life of me, why programmers don't document their source code, especially open-source programmers. How is anyone supposed to contribute to their project if the hurdle is set so high? Hell, how do they remember how a piece of code works if they haven't seen it in a long time? It boggles the mind.

I don't have any good theories for why this is...just a disparaging one. Every time I encounter this problem, I get a vivid image of Gollum grasping some source-code printouts and hissing "Nooooo! My preciousssssss...."

I certainly document my open-source code. My biggest project to date is a temporal analog-video denoiser called y4mdenoise. Feel free to look at the code, if you'd like to see an example of what I'd consider a proper level of documentation. Start with the high-level overview and find out for yourself.

The prevalent attitude seems to be 'The code is there for you to modify. Do it yourself.' For the average user, that could mean developing proficiency in some programming language, familiarity with that software's architecture before they even begin to understand how to get what they want.

Making matters worse...most open-source projects are severely under-documented. Even though the source is available, getting past the hurdle of severe under-documentation is too much of a hassle. It takes dedication to get to the point where one can contribute meaningfully to an open-source project, and not for any good reason — it shouldn't take that much effort.

Making matters even worse...in my experience, most open-source-project maintainers will resist documentation. I just went through this with an open-source project I've been interested in a long time. Since the source-code had practically no comments whatsoever, I took it upon myself to learn the subject matter (in this case, NOT an easy task), then learn large parts of the source code. Then, being the sort that's willing to contribute, I offered to document the code. The maintainer was willing, even eager, for it. Then I submitted my first patch...and he immediately changed his tune. He found my documentation to be "excessive", and quoted chapter 8 of the Linux kernel coding guidelines to bolster his case. Frankly, I couldn't disagree more with his viewpoint.

I'll never understand, for the life of me, why programmers don't document their source code, especially open-source programmers. How is anyone supposed to contribute to their project if the hurdle is set so high? Hell, how do they remember how a piece of code works if they haven't seen it in a long time? It boggles the mind.

I don't have any good theories for why this is...just a disparaging one. Every time I encounter this problem, I get a vivid image of Gollum grasping some source-code printouts and hissing "Nooooo! My preciousssssss...."

I certainly document my open-source code. My biggest project to date is a temporal analog-video denoiser called y4mdenoise. Feel free to look at the code, if you'd like to see an example of what I'd consider a proper level of documentation. Start with the high-level overview and find out for yourself.

I was skeptical at first, but then I realized who wrote it and ... there went a few hours of my life this weekend. After I hacked the source to read the right buttons for my dualshocks (pesky eight button limit, oh well remap 0-3 to 11-14 && debuild) it stole some neurons from a few friends. Really nice in 1920x1080 / 50" glory (I knew I got that fancy graphics card for something). Kind of like playing tempest 2000 inside of speedmine (happens to be one of my favorite xscreensavers).

There's always Mumble. It's end to end encrypted and open source. Of course, using it is a BITCH. Mumble is a poster child for why encrypted communications never catches on. I'm as technical as they come, and I got impatient trying to get Mumble and Murmur (the client) working together. Manually creating and exchanging certificates is obnoxious.

But it works, despite being obnoxious. It's not a Skype competitor. There's no gateway into the phone network. But it is a Teamspeak competitor. In your case, the lack of a phone network gateway is probably a feature. It doesn't demand you identify yourself to anyone at all. All you need is to give people you want to talk to the Mumble server IP or hostname and the certificate.

Now that Skype is becoming unfriendly, maybe Mumble will get some love and some of the more annoying usability problems will get fixed.

Looks like it would be a fun game. Do you know if anyone is maintaining it for current Linux systems? I found this, but it is from 2005 and both the D language and OpenGL have evolved quite a bit since then. I was hoping to play it on a GL ES device (GCW Zero).

IHe tries to generalize it, but it seems like he's talking about outlook specifically not working with gmail. Maybe he should try not using outlook? I dunno. Maybe that's just me. I hate outlook, but my work seems to love it. I have to forward my work e-mail to a gmail account to use it on anything besides outlook.

If you have access to your Exchange server's web interface, try this.

The problem is, in part, Lisp's syntax. Most people don't want to read code written in lisp, because (+ (* 3 4) 5) is a big pain. You might look into http://readable.sourceforge.net/ - it extends Lisp s-expressions with additional abbreviations, making it much easier to read.

I'm responding to this, because I agree that LMMS is a great program. A little awkward to use sometimes but still cool. I would also like to mention to the Ardour doubters out there that using the Calf plugins makes Ardour a whole new piece of software http://calf.sourceforge.net/ .

Why? Compilers are pretty simple; Difficult for a lot of people to conceptualize, yes, but for those who can make that leap of understanding, not terribly difficult to design

Err, no. Let's look at C++ in particular, as it's pretty much a worst case when it comes to compiler implementation.

These guys make a living working on a C++ front-end. A front-end only. Intel licence it because writing their own C++ front-end would be a tremendous effort; C++ is a hugely complex language, for machines (i.e. compiler front-ends) as well as for humans. The optimisation and back-end work is even more effort, especially if you want to be a serious competitor among today's compilers, which gcc certainly does.

Getting these things right is, to put it mildly, not easy. Bugs in optimising compilers really do happen. Here's a compiler-bug warning I ran into just this week.

Let's also not forget the scope of the gcc project: it's not 'just' a C++ -> x86/AMD64/IA-64 compiler, the way ICC is. It reads in source-code in C, C++, Objective-C, Fortran, Java (in theory...), Ada, and Go, and emits machine code for a great many CPU architectures.

Compilers are a legitimate sub-field of computer science, in the same way operating systems are. IBM invested in JikesRVM, a 'Research Virtual Machine' (for Java) for a reason. It's something some academics specialise in. Dismissing the field as "pretty simple" is hardly fair to its researchers and implementers.

[non](http://non.tuxfamily.org/wiki/About)
[lmms](http://lmms.sourceforge.net/)
[nama](http://freeshell.de/~bolangi/nama)

Will there be a command-line version und can I pipe it to /dev/snd ?

I'm guessing the answer would be no ;-)

Sox (free, open source) is what you want for that type of processing.

http://sox.sourceforge.net/

Peace,
Andy.