Slashdot Mirror

Can't you just emulate the processor with QEMU and run the app in a sandboxed environment ?

https://github.com/hackndev/qe...

------

https://stackoverflow.com/ques...

If a daemon doesn't log something, ...

That is not correct at all. MongoDB outputs that error to stderr. It has *nothing* to do with logging. Attempting to start the service with systemctl hides the stderr output. It also isn't logged in the journal. That is a serious bug. You need to stop irrationally defending something that is broken.

Tomorrow I'm having my best developer look at the source to systemd from https://github.com/systemd/sys... , and I'm going to see if he can track down the problem. I noticed systemd has 397 contributors which is awesome. That proves it is a very healthy open source project. It just has problems that need to be fixed. I'm putting my money where my mouth is and dedicating resources to see if we can get this fixed. Not logging stderr is a serious bug.

Indeed, ANY language feature can be abused.

Let's abuse whitespace! O_o

Since /. formatting for code is SO fucked up that I can't even paste the source code, here's a link to it ..

  * https://gist.github.com/cgoldb...
  * http://www.perlmonks.org/?node...

So your use case allows for reboots - not every one does. And far more use cases allow for scheduled reboots, but not necessarily immediate reboots as soon as a security vulnerability is published.

Fedora-derived (e.g. EL7) and Ubuntu disros can use Redhat's kpatch support (but no patches provided in EL7 -updates yet) whilst SuSE has kGraft which as of November has had a real update stream available. People don't run these things because it's easier than rebooting.

Besides, fix your runtime problems, set up a test cluster, and monitor your systems better - relying on side-effects is never a good plan.

If anyone's particularly interested in coroutines, we in the ScummVM project, which provides a reimplementation of lots of old classic adventure games, implemented a fairly clean C++ coroutine implementation, which we already use for two different games were originally threaded. ScummVM runs on a variety of different hardware, not all of which support threading, so we had to come up with a way to run these games using only a single thread. See https://github.com/scummvm/scu... and coroutines.cpp if you're interested.

You forgot the MakeRocketLauncherGoNowFactory, the MakeRocketLauncherGoNowFactoryFactory, the MakeRocketLauncherGoNowException, the ...

Exactly. Check out EnterpriseQualityCoding/FizzBuzzEnterpriseEdition for a "proper" example:
https://github.com/EnterpriseQ...

No centralized information hosting company - not Google, Facebook, Twitter, Microsoft, or others - can solve this problem, because as you said a National Security Letter will compel them to provide the requested information or be shut down.

That's not end-to-end encryption. Only the recipient of an end-to-end encryption can decrypt the message, no matter who hosts it. There's actually a Chrome extension for it now.

https://github.com/google/end-...

Granted, public key distribution should be decentralized, but that's not an insurmountable problem.

I think I learned about uBlock from someone's sig here. It accomplishes the same goal as Adblock Plus/Edge, but uses significantly less memory. A freshly launched Firefox instance with Adblock Plus (only one empty tab open) used slightly over 230MB of RAM; with uBlock that figure is down to around 100MB.

I too first started using Firefox when it was called Phoenix, but I disagree that Mozilla has failed. In my experience Firefox is fast and responsive. Resource-minimalness (is that even a word?) isn't an issue for me, as I don't think Firefox requires unreasonable amounts of disk space or RAM. Especially after switching to uBlock. I suppose RAM usage starts to matter more if you like to keep hundreds of tabs open; it's a valid concern but not relevant for me.

(I couldn't figure out how to get the micro sign to work on Slashdot.)

Wow, what an easy pitch. :-) At Mozilla, we've put together a tool called DXR ( https://github.com/mozilla/dxr... ). It indexes your code and lets you do text and regex searches. But if you can get your project to build under clang, you can really have some fun, with queries that find...

* Calls of a function (great for dead code removal)
* Uses a type
* Overrides of a method
* Uses and definitions of macros
* etc., etc., etc. There are something like 24 different structural queries you can do.

Because all of this is informed by the internal data structures of the clang compiler, it's nigh on 100% accurate (aside from more dynamic behaviors like sticking function pointers in a table and passing them around). You can also explore a hyperlinked version of the source, bouncing from #include to #include and drilling into methods.

Here's how to set it up: https://dxr.readthedocs.org/en...
Here's our production instance you can play with: https://dxr.mozilla.org/mozill...

If you run into trouble, pop into #static on irc.mozilla.org, and we'll be happy to help you.

"What's the case for...not just world language is good, world language is well-rounded, but world language is so super-duper-duper good that you should spend two years of your life doing them and specifically better than something else like coding?"

Steve Jobs has this one:

“I decided to take a calligraphy class to learn how to [learn calligraphy]. I learned about serif and sans-serif typefaces, about varying the space between different letter combinations, about what makes great typography great....None of this had any hope of any practical application in my life. But 10 years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would never have multiple typefaces or proportionally spaced fonts.

If all you do is write code and never learn to communicate, you're going to end up writing code like Microsoft does (seriously, 16,000 lines in a single file? And there are plenty of other lengthy files too, that's not really an anomaly).

WinForms has worked fine on Linux for a long time. WinForms in Mono. Even better if you declare a folder named "C:" and then declare 5-6 folders named "Program Files", "Program Files (x86)", "Users", "AppData", etc. under that. If you declare the right folder scheme, a large percentage of Windows applications will run perfectly on Mono as is.

Microsoft Patent Promise for .NET Libraries and Runtime Components

Microsoft Corporation and its affiliates ("Microsoft") promise not to assert
any .NET Patents against you for making, using, selling, offering for sale,
importing, or distributing Covered Code, as part of either a .NET Runtime or
as part of any application designed to run on a .NET Runtime.

https://github.com/dotnet/core...

The MIT License (MIT)

Copyright (c) Microsoft Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

https://github.com/dotnet/core...

If you weren't so hung up on flogging a dead horse for mod points, MS has covered patents and licensing in the codebase itself.

Microsoft Patent Promise for .NET Libraries and Runtime Components

Microsoft Corporation and its affiliates ("Microsoft") promise not to assert
any .NET Patents against you for making, using, selling, offering for sale,
importing, or distributing Covered Code, as part of either a .NET Runtime or
as part of any application designed to run on a .NET Runtime.

https://github.com/dotnet/core...

The MIT License (MIT)

Copyright (c) Microsoft Corporation

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

https://github.com/dotnet/core...

If you weren't so hung up on flogging a dead horse for mod points, MS has covered patents and licensing in the codebase itself.

Efficiency

uBlock instead in both Firefox and Chrome.

how does it get better than that?

Quite a few ways, actually, all of which would have been apparent had you just clicked the link, but if you need it spelled out for you...
1) uBlock is available for multiple browsers and is available via official stores/sites for at least some of them (with plans to get into the others). Doesn't matter to you, perhaps, but it does matter to some of us, especially if we're looking for something to recommend to non-techie friends and family.

2) uBlock actually leads to a reduced memory footprint for your browser, whereas AdBlock Plus (on which Edge is based), increases the browser's memory footprint.

3) uBlock has SIGNIFICANTLY better CPU performance than ABP and its competitors. Nearly an order of magnitude.

4) uBlock is slightly better at blocking unnecessary server hits. About twice as good as ABP, and just a shade worse than Ghostery.

All of which is to say, by nearly every measurable metric, it's better than the thing that you think is the best.

ÂBlock (read as "micro-block") has smaller memory footprint than AdBlock (and therefore Adblock Edge), and can use the same major privacy lists (EasyList, EasyPrivacy, Peter Lowe's Ad Server).

Faster, better, hackable and free. https://github.com/gorhill/uBl...

Basic blocking: https://github.com/gorhill/uBl...
More extensive blocking: https://github.com/gorhill/uMa...

Extensions are available for Chrome/Chromium. It seems Firefox is (getting) supported as well.

Basic blocking: https://github.com/gorhill/uBl...
More extensive blocking: https://github.com/gorhill/uMa...

Extensions are available for Chrome/Chromium. It seems Firefox is (getting) supported as well.

Regular Expression Grammars. If Perl6 consisted of nothing else, I'd still love it.

Although Python 3 is objectively better in many ways, the improvements don't seem compelling enough to me to bother to really learn

Well, that is catch-22 in action -- you will probably not really get the improvements unless you actually explore them. If reading about the changes is not enough (though perhaps it is, but you have not read enough), and all the Python developers saying "you should really go to Python 3" is not enough, then perhaps the only thing that will convince you is diving in and experiencing the differences on a deeper level.

For me, as someone who has not grown up in an unambiguous ASCII-society and has felt the pains of handling input in strange encodings, the improved Python 3 string handling is a killer feature on its own. I will not look back.

There are two libraries holding back some of my projects: wxPython (where a Python 3 rewrite is under way) and MySQLdb (a Python 3 rewrite was under way, but has been dead since 2012; today there are several options, though). Those projects stay in the "if it aint broke"-pile until further notice. Other than those (well, only wxPython, really), I have no gripes about missing modules any longer.

And I still kindda like "print" as a statement.

That is probably the most superficial change of them all, fixable by search-and-replace, yet the one that people get stuck on :-) . It makes a lot more sense to have the parenthesized form, immediately allowing automatic string continuation over lines, optional keyword arguments (end='' is quite useful), etc.

Although Python 3 is objectively better in many ways, the improvements don't seem compelling enough to me to bother to really learn

Well, that is catch-22 in action -- you will probably not really get the improvements unless you actually explore them. If reading about the changes is not enough (though perhaps it is, but you have not read enough), and all the Python developers saying "you should really go to Python 3" is not enough, then perhaps the only thing that will convince you is diving in and experiencing the differences on a deeper level.

For me, as someone who has not grown up in an unambiguous ASCII-society and has felt the pains of handling input in strange encodings, the improved Python 3 string handling is a killer feature on its own. I will not look back.

There are two libraries holding back some of my projects: wxPython (where a Python 3 rewrite is under way) and MySQLdb (a Python 3 rewrite was under way, but has been dead since 2012; today there are several options, though). Those projects stay in the "if it aint broke"-pile until further notice. Other than those (well, only wxPython, really), I have no gripes about missing modules any longer.

And I still kindda like "print" as a statement.

That is probably the most superficial change of them all, fixable by search-and-replace, yet the one that people get stuck on :-) . It makes a lot more sense to have the parenthesized form, immediately allowing automatic string continuation over lines, optional keyword arguments (end='' is quite useful), etc.

Also, have you ever run a Windows guest under KVM? The guest drivers, which are required to bring performance to a level anywhere near VirtualBox, aren't anywhere near what I would call "stable" yet. Don't get me wrong, I'm a fan of KVM, and use it exclusively at home for both servers and my Windows-while-I'm-booted-to-Linux machine. But it's just not quite as ready for mainstream as VirtualBox is.

I've used VirtualBox for a long time without many complaints, but the bug list is starting to pile up; the user base has noticed; and certainly Oracle is in-part to blame.

https://github.com/jessek/hash...

this came from someone working in the us mil and it's an amazing program. not all .mil projects are bad.

https://github.com/USArmyResearchLab/Dshell/blob/master/LICENSE.txt

This project constitutes a work of the United States Government and is not subject to domestic copyright protection under 17 USC 105.

However, because the project utilizes code licensed from contributors and other third parties, it therefore is licensed under the MIT License. http://opensource.org/licenses/mit-license.php. Under that license, permission is granted free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the conditions that any appropriate copyright notices and this permission notice are included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Yeah. I think Kirt's ranting about the "tyranny of Google" is BS. Although I can sort of understand where they MIGHT be coming from after the Cornerstone mess - but that was probably a no-win situation for everyone involved.

That said, I fully agree with the people that are seeing a slow move towards AOSP becoming more and more closed source. One by one, the following happens:
Google wants to integrate GMS further with a given app (no problem here)
Google forks said app to add GMS integration (no problem here, although moving it to some sort of plugin-style approach might work better as it avoids what has proven to be the inevitable result)
Google stops development on the open-source component that the GMS-integrated component was forked from within AOSP, leaving it to rot. This annoys people and is where the perception that Google is slowly "closing down" AOSP comes from.

There's also the fact that AOSP's strict scope-limiting to Nexus devices only tends to cause people to not bother upstreaming to it - https://android-review.googles... for example

Also annoying is the fact that Google still builds AOSP using prebuilt kernel images, which often depend on toolchains deleted from AOSP. Also, AOSP uses kernel headers that just happen to match the actual kernel itself in structural organization but have different names, so Bad Things happen if you try to build AOSP against actual kernel headers now:
https://github.com/omnirom/and...
and
https://github.com/omnirom/and...

Yeah. I think Kirt's ranting about the "tyranny of Google" is BS. Although I can sort of understand where they MIGHT be coming from after the Cornerstone mess - but that was probably a no-win situation for everyone involved.

That said, I fully agree with the people that are seeing a slow move towards AOSP becoming more and more closed source. One by one, the following happens:
Google wants to integrate GMS further with a given app (no problem here)
Google forks said app to add GMS integration (no problem here, although moving it to some sort of plugin-style approach might work better as it avoids what has proven to be the inevitable result)
Google stops development on the open-source component that the GMS-integrated component was forked from within AOSP, leaving it to rot. This annoys people and is where the perception that Google is slowly "closing down" AOSP comes from.

There's also the fact that AOSP's strict scope-limiting to Nexus devices only tends to cause people to not bother upstreaming to it - https://android-review.googles... for example

Also annoying is the fact that Google still builds AOSP using prebuilt kernel images, which often depend on toolchains deleted from AOSP. Also, AOSP uses kernel headers that just happen to match the actual kernel itself in structural organization but have different names, so Bad Things happen if you try to build AOSP against actual kernel headers now:
https://github.com/omnirom/and...
and
https://github.com/omnirom/and...

Google is working on enabling OpenPGP-encrypted e-mail for Gmail with a Chrome extension: https://github.com/google/end-...

Or you can have it on Firefox right now with enigmail. Or well, you could. Maybe it doesn't work any more. I had nobody to exchange encrypted email with, so I no longer have it installed.

Yup, that is the issue. I'm weakly hopeful that having Google behind it will encourage wider use. Weakly.

Google is working on enabling OpenPGP-encrypted e-mail for Gmail with a Chrome extension: https://github.com/google/end-...

Or you can have it on Firefox right now with enigmail. Or well, you could. Maybe it doesn't work any more. I had nobody to exchange encrypted email with, so I no longer have it installed.

Though you have to trust AWS with the plain text at some time since every mail server and client has to hand the message over in plain text (it may come in over an encrypted tunnel, but it needs to be decrypted by their mailservers).

No, it doesn't. S/MIME, PGP-mail, etc. Of course that only works if the party you're e-mailing can also use client-side e-mail encryption.

Google is working on enabling OpenPGP-encrypted e-mail for Gmail with a Chrome extension: https://github.com/google/end-...

C# is no longer proprietary. Get your biases updated, people!

Ok, has anyone ever written an OS kernel in Pascal? How about bare-metal code which tweaks registers?

They sure have. You, too, can write your own OS in Pascal. Nikolay Nikolov did.

Delphi had many great aspect, especially compile time. My wife and I put about six person years into a project together, much of the time working in Delphi. I knew (and even had taught at the college level C/C++), but she knew mostly Pascal. We did some work in C++, but got hit by the compile times (this was back working with PCs starting around 1995) as well as all the other issues writing in C++. Then we did some in Digitalk's Smalltalk/V, but got worried about lack of support for the proprietary version we were using (we could not have guessed that later is became a free-as-in-beer Smalltalk Express). Wish we had kept to Smalltalk though, as then we could have moved to Squeak a couple years later, and my wife and I really liked Smalltalk. But Smalltalk back then was also slow and had some other limits. So we moved to Delphi (the earliest versions, never moving to later versions beyond 2.0).

Here is GPL'd source for of our garden simulator in Delphi:
http://www.kurtz-fernhout.com/...

GPL'd Delphi source and translations for two other applications (PlantStudio and StoryHarp software) is here:
https://github.com/pdfernhout/...
https://github.com/pdfernhout/...

In retrospect, I think maybe we could have made the C++ approach also work better by writing unit tests for parts of the code and compiling only them in small projects. And I think I'd have much rather have the code in C++ right now than Delphi as far as long-term portability, including now translating to asm.js for web browser deployment.

But, for good or bad, I made the decision a decade ago to port it, and wrote code to parse Delphi and spit out Java and Python (doing a lot of the heavy lifting, but you need to futz with the GUI stuff and some other changes). I only got the StoryHarp app working (in a limtied way) in Java, plus I got the guts of the PlantStudio drawing algorithm in Python for a test for the OLPC.

I'm moving more into JavaScript now, for easy deployment in web browsers, so I might modify those tools to do JavaScript now? But not sure it was worth it, given the rise of Lazarus and the fact that, generally, you learn so much from writing an application that if you were to build it again, you'd do it differently.

But, in any case, Delphi was overall a pleasure to work in as far as a compiled language. Speedy. Fast turn around. Good debugging (although some library bugs with memory leaks were frustrating in the early versions -- we used memmond and its memory leak patches, plus other patches I created and found for the Delphi VCL).

When Squeak first came out, I played with generating Delphi pascal for its VM to use for Windows, but after the Windows port came out, lost some interest in that, and also got sidelines by looking into Squeak -> Newton porting. In retrospect, I wish I had finished the Squeak to Delphi port and code generation tooling, and never bothered working towards a Newton Port as the Newton OS did not want to support any more C++ than small routines, the OS's event loop conflicted with the Squeak polling architecture, Newtons had too little RAM, and of course the Newton was to be abandoned. Meanwhile, Delphi (especially via Lazarus) is still going strong!

Delphi had many great aspect, especially compile time. My wife and I put about six person years into a project together, much of the time working in Delphi. I knew (and even had taught at the college level C/C++), but she knew mostly Pascal. We did some work in C++, but got hit by the compile times (this was back working with PCs starting around 1995) as well as all the other issues writing in C++. Then we did some in Digitalk's Smalltalk/V, but got worried about lack of support for the proprietary version we were using (we could not have guessed that later is became a free-as-in-beer Smalltalk Express). Wish we had kept to Smalltalk though, as then we could have moved to Squeak a couple years later, and my wife and I really liked Smalltalk. But Smalltalk back then was also slow and had some other limits. So we moved to Delphi (the earliest versions, never moving to later versions beyond 2.0).

Here is GPL'd source for of our garden simulator in Delphi:
http://www.kurtz-fernhout.com/...

GPL'd Delphi source and translations for two other applications (PlantStudio and StoryHarp software) is here:
https://github.com/pdfernhout/...
https://github.com/pdfernhout/...

In retrospect, I think maybe we could have made the C++ approach also work better by writing unit tests for parts of the code and compiling only them in small projects. And I think I'd have much rather have the code in C++ right now than Delphi as far as long-term portability, including now translating to asm.js for web browser deployment.

But, for good or bad, I made the decision a decade ago to port it, and wrote code to parse Delphi and spit out Java and Python (doing a lot of the heavy lifting, but you need to futz with the GUI stuff and some other changes). I only got the StoryHarp app working (in a limtied way) in Java, plus I got the guts of the PlantStudio drawing algorithm in Python for a test for the OLPC.

I'm moving more into JavaScript now, for easy deployment in web browsers, so I might modify those tools to do JavaScript now? But not sure it was worth it, given the rise of Lazarus and the fact that, generally, you learn so much from writing an application that if you were to build it again, you'd do it differently.

But, in any case, Delphi was overall a pleasure to work in as far as a compiled language. Speedy. Fast turn around. Good debugging (although some library bugs with memory leaks were frustrating in the early versions -- we used memmond and its memory leak patches, plus other patches I created and found for the Delphi VCL).

When Squeak first came out, I played with generating Delphi pascal for its VM to use for Windows, but after the Windows port came out, lost some interest in that, and also got sidelines by looking into Squeak -> Newton porting. In retrospect, I wish I had finished the Squeak to Delphi port and code generation tooling, and never bothered working towards a Newton Port as the Newton OS did not want to support any more C++ than small routines, the OS's event loop conflicted with the Squeak polling architecture, Newtons had too little RAM, and of course the Newton was to be abandoned. Meanwhile, Delphi (especially via Lazarus) is still going strong!

I just looked at https://github.com/torvalds/li... (picked almost at random.) There are some funny things in there but in general it's pretty readable. I realized that C starts looking as alien to me as assembly looked to me when I was writing C and Pascal at university. Not that I couldn't write in assembly but wow, it's so time consuming that it's only for when there are no alternatives.

libressl-2.1.3.tar.gz 21-Jan-2015 2.7M. For you non Open BSD users: portability wrappers. Full Source.

libressl-2.1.3.tar.gz 21-Jan-2015 2.7M. For you non Open BSD users: portability wrappers. Full Source.

It seems that 3da4340b7c3367b082cfa2971d2557561484ef1c is the particular commit.

"D offers compilers for all three platforms (Windows, Mac and Linux) as well as FreeBSD."

Note that two of those compilers use GCC and LLVM as their back-ends. In practice, this means that you can use D on any architecture they support. For example, here's a patch that adds D support to buildroot toolchains.

I do agree that the third-party libraries available are pretty limited though.

Rule number one in C++ : avoid the preprocessor unless you really have to use it.

Things like:

#ifdef UNTESTED_FEATURE
                #include "crazy_new_untested_code.c"
#endif

Are a blight, and one of the first things that I remove from C++ code.
The preprocessor does not work on the same level as the compiler, and therefore has no knowledge of rather important aspects of the language like scoping or namespaces. If something can be done as a language-level constructor instead of a preprocessor macro, do so. A good example is a templated min() function vs. a MIN() macro. Another one are awful sins like "#define DWORD unsigned long" . Oh, and include guards? Unfortunately a necessary evil, because #include is a relic from the past, and we have no modern, proper replacement (something like packages, modules, units in other languages). And no, #include + include guards are not "good enough". Hacks like the pimpl idiom are necessary because of the stupidity of #include. I hope the C++ committee gets modules done in the next C++ standard revision. Then *finally*, I can say goodbye to C++ headers.

Your example with the untested feature can be solved by isolating the crazy untested code in its own module, and simply *not enabling that module in the build scripts*. Not by filling code with #ifdefs.

WebKit unfortunately uses #ifdefs in its code, even in its headers. Example: https://github.com/WebKit/webk... and it is a horrible design approach. It completely violates the open/closed principle, and as a result, integrating a new graphics API or toolkit is not as straightfoward as it could be.

Of course the preprocessor can sometimes be useful, but it is not as much of a killer feature as you make it to be. In C it needs to be used much more often than in C++.

Java is about the worst starting language possible. All the students will see is the horrible syntactic clutter it comes with. It will them take months to start to be able to differentiate between code that actually does something and syntax that is just there to satisfy the autistic compiler.

Ugh, yeah, I hate that about Java. Even tried Scala but it wasn't working out for me either.

From a Perl user's perspective, Groovy looked promising but I kept running into problems even using it for anything. Groovy1 or Groovy2? Oh you want to use it with Android? Go get the dev version and compile it. Except it still only half works because it's too new. Plus the runtime adds a ton of crap, memory use is high even for simple things, etc. Halfway through I decided Groovy didn't look interesting enough to deal with all that shit.

Then I learned about JRuby and Mirah. Used Ruby and JRuby to get accustomed to the syntax, even mucked about with using it on Android via Ruboto, all of which was dead simple to set up and get started using. Good for quick prototyping, and in a lot of ways, Ruby itself feels like someone took Perl and made the OO less shit. I never had a reason to learn it before, but now I kind of wish I had sooner.

Anyway, since this is a reply about Java, the rest of this is going to be about Mirah . . .

Mirah takes Ruby-like code, turns it into Java, and compiles it down to class files. No runtime, no extra overhead, still statically-typed. Uses Java APIs inside Ruby-esque syntax. The resulting programs are fast and small. Has a crazy macro system that's used to provide syntactic sugar, such as Ruby style constructs like 10.times { |x| puts x } or attr_accessor(:field_name) without needing a runtime. The macro system's usable in mirah programs, too, and so you can create quality-of-life improving methods that can be used on existing classes, like adding new methods to String without having to create a new class, so you can create all sorts of boilerplate-saving shortcuts.

For an idea of how the code looks in use, there's this example of what a really basic Swing demo looks like in Mirah, along with a bunch of other examples in their github repo.

So far I really like it, but all isn't perfect. Getting set up is easy, but the documentation is fairly lacking so I've had to do a lot of experimentation after poking around their google groups page, github wiki, and source code. Especially if something goes wrong. Took me forever to figure out that I needed to add mirahc.jar to $CLASSPATH to appease an oddity of the macro compiler when using multiple source file with macros, for example. Sometimes the mirah compiler's syntax errors are really freaking useless, too, and you have to go hunting for where the error really is.

Still, it's been more straightforward to actually use once set up, and there's a Ruboto-style android generator tool called Pindah that helps simplify the Mirah+Android scenario, so I've been enjoying experimenting with it both on desktop and mobile. Being able to ditch most of the boilerplate shit and focus on getting something useful done is really nice. I'd rather deal with its oddities than Java syntax any day.

Java is about the worst starting language possible. All the students will see is the horrible syntactic clutter it comes with. It will them take months to start to be able to differentiate between code that actually does something and syntax that is just there to satisfy the autistic compiler.

Ugh, yeah, I hate that about Java. Even tried Scala but it wasn't working out for me either.

From a Perl user's perspective, Groovy looked promising but I kept running into problems even using it for anything. Groovy1 or Groovy2? Oh you want to use it with Android? Go get the dev version and compile it. Except it still only half works because it's too new. Plus the runtime adds a ton of crap, memory use is high even for simple things, etc. Halfway through I decided Groovy didn't look interesting enough to deal with all that shit.

Then I learned about JRuby and Mirah. Used Ruby and JRuby to get accustomed to the syntax, even mucked about with using it on Android via Ruboto, all of which was dead simple to set up and get started using. Good for quick prototyping, and in a lot of ways, Ruby itself feels like someone took Perl and made the OO less shit. I never had a reason to learn it before, but now I kind of wish I had sooner.

Anyway, since this is a reply about Java, the rest of this is going to be about Mirah . . .

Mirah takes Ruby-like code, turns it into Java, and compiles it down to class files. No runtime, no extra overhead, still statically-typed. Uses Java APIs inside Ruby-esque syntax. The resulting programs are fast and small. Has a crazy macro system that's used to provide syntactic sugar, such as Ruby style constructs like 10.times { |x| puts x } or attr_accessor(:field_name) without needing a runtime. The macro system's usable in mirah programs, too, and so you can create quality-of-life improving methods that can be used on existing classes, like adding new methods to String without having to create a new class, so you can create all sorts of boilerplate-saving shortcuts.

For an idea of how the code looks in use, there's this example of what a really basic Swing demo looks like in Mirah, along with a bunch of other examples in their github repo.

So far I really like it, but all isn't perfect. Getting set up is easy, but the documentation is fairly lacking so I've had to do a lot of experimentation after poking around their google groups page, github wiki, and source code. Especially if something goes wrong. Took me forever to figure out that I needed to add mirahc.jar to $CLASSPATH to appease an oddity of the macro compiler when using multiple source file with macros, for example. Sometimes the mirah compiler's syntax errors are really freaking useless, too, and you have to go hunting for where the error really is.

Still, it's been more straightforward to actually use once set up, and there's a Ruboto-style android generator tool called Pindah that helps simplify the Mirah+Android scenario, so I've been enjoying experimenting with it both on desktop and mobile. Being able to ditch most of the boilerplate shit and focus on getting something useful done is really nice. I'd rather deal with its oddities than Java syntax any day.

As the proprietary vendors business models change, Linux video editing has increasing advantages, e.g. the lack of "subscription" business model. Avidemux is very powerful and actively developed.

If you have a Windows install and you buy Adobe Premiere Elements for $90, you will discover you must sign in, and Premiere Elements will max out your incoming internet connection for the entire time the program is open. But Premiere Elements works fine for video editing if you disable networking in control panel. So what's it doing with all that bandwidth?!

Here you go: http://www.oracle.com/technetwork/systems/opensparc/index.html. Not HDL, or even the CPU: https://github.com/open-power. Free graphics is another thing, but wasn't there a GPL FPGA based display controller somewhere?

I agree, it's not really an issue, at least for me. But it seems people sometimes get into trouble with it as they edit other people's Python in some random editors. For example, it's nice that people are using my code even on Windows, but apparently some portability issues remain :-j

Your vbnc was last updated in 2010, and targets Visual Basic .NET 8, which was released with Visual Studio 2005. The VBNC compiler has not had any significant updates since 2011.

Visual Basic .NET is now on version 12. vbnc is horribly behind, and it does not appear to be actively supported. If your instructor were to use any newer language features, such as lambdas, iterators or asynchronous programming, you would not be able to use VBNC to compile that code and would probably have to resort to using Windows somehow.

On the flipside, Python now comes standard with most Linux distributions, and is standard with Mac OS X. It's very simple to install on Windows and even comes with a bare-bones IDE for editing code. In every respect, it is easier to get started using Python than to start using VB .NET, especially on non-Windows platforms.

If it is free software, you should have the possibility of altering the program so that it does not ask for money and you are permitted to distribute such versions.

You can, the source is available here. And it is apparently licensed under the GPLv3.

Why run a mac at all if your goal is to use Linux? PCs are a ton cheaper and in most cases just as good.

I have been a Linux desktop user for over 10 years, love it, even back in the days when a lot of things, especially internationalization required tweaks.

Been using OSX for a year, the touch pad plus safari experience is spectacular, but there a ton of things I don't like:
File browsing - Finder abstracts too much away from power users
Package uninstall - pieces everywhere, no free reliable way to track files down, which is unfortunate since it should be one of the basic features
var/folders - I think it's a brainfuck decision to design your cache like this
Safari itself - ... ... the list goes on, it comes down to how customizable the OS is, which Linux is much better.

So why buy a Macbook?
You have to consider overall user experience when you're talking about pricing. Their hardware is superb, till this day I'm still loving the aluminium design, it makes you feel good when you're using it. The charger, the connector of the charger, the form factor, the battery life, everything is just perfect. There's also the prestiage when you pull out a Macbook. (although I mainly just it at home, and it's something I used to despite. Sadly it is valid thing, hello taste/artistic sense? ) You get all these things and markup isn't really that much. I consider it one my best gadget purchases in my life.

If it weren't for the non-existence webcam driver for my late 2013 version, I would be running Linux on it most of the time.
Latest development I could find.
So IMO buying a Macbook to Linux isn't that stupid.

In this case they're giving away some but not all of the activities included with gcompris with the Android version. It's possible, then, that the core software remains Free Software, while those other activities (for which you also have to pay on Windows and MacOS) are commercial, for-pay software.

However, I'm already downloading some stuff right now, so I'm not downloading the 280MB tarball to find out

No worries. I’m happy to tell you that all of GCompris, each and every activity, is free software. If you download the source code, you get the source code for all the activities.

If you want to, you can compile the software yourself. (Actually, there’s not much compiling required. GCompris Qt is written in Qt Quick, so it’s mostly just JavaScript code, that doesn’t need any compiling.) You can get the latest version of the source code at the KDE Git repository, or at a GitHub mirror.