What I don't like about JNI is how it approaches wrapper generation - essentially assuming you are writing your C/C++ code *specifically* to be used in Java. Case in point being the fact you basically have to directly modify your header files. This can of course be avoided by writing code/headers that include JNI and your native headers - but then on top of that you need to write wrapper headers and wrapper code. Most other wrapper systems don't make this assumption and just let you write an interface or some wrapper code and be done with it.

On top of that actual generation of the wrapped binaries isn't nearly as smooth and integrated as say Ruby native gems. Maybe it can be set up to be cleanly automated so everything will be generated for your build target at compile time but in my currently limited time dealing with Java I've yet to see such a setup.

I would like to point out I'm no expert on JNI and have only used it twice before going all SWIG. Actually if you know of a good example or guide for JNI that could set me straight I'd love to see it.

You're talking about what we would call "managed blocks" in the systems we used. We didn't have malloc even, we literally just had a block and a pointer to the head and we'd write our own new and delete functions that would just mark or unmark sections of a map.

There are however plenty of systems that do have native new and delete that are specifically written as RTOS embedded systems. EG: ITRON which is found in a lot of automotive [sub]systems.

Generally though most embedded systems set up their memory statically, like you pointed out. Parent poster here however is referring to a media system where some blocks (like display buffers) would be static there are probably many different modes so not a single function application and not something where one globally static map would fit all cases.

I'd say you're mostly correct and for the question this guy is posting I'd say you're dead on.

Personally I've fit into the "very few" category you point out with specialized applications / working with a non-standard protocol server / interfacing with network hardware so much that even if I'm writing a standard HTTP client I write the headers and handle the streams myself. With HTTP 2.0 coming though I think I may stop that practice. Still, anyone writing a networking client should at least play with HTTP at least once - it's a very easy protocol to handle with tons of documentation and a myriad of reference implementations.

I program raw TCP in C++.

I think maybe you meant to say "do you realize people program raw TCP in C++?" or something like that.

Also, I agree with you that the person asking the question here should probably look for something else. It sounds like they are in over their head and I don't see them optimizing multi-threaded networking applications with real time IO in valgrind any time soon (though it sounds like an interesting Friday afternoon for me).

JNI is the absolute most awful native interface system I have ever seen. If you absolutely must go the JNI route may I recommend using SWIG to generate things for you. It will require some additional wrapping but at least it won't make you want to end your own life.

As for performance penalties you'll have the additional overhead of a JVM as well. The whole setup you are proposing I'm guessing you've implemented before and are comfortable with but to me it sounds messy and unnecessary - especially with so many good networking libraries available for C++.

ASIO is in fact part of Boost now and I personally like it. The thing you need to remember though is that ASIO is not an HTTP client or really any type of client at all - if you want to do HTTP you'll need to write the HTTP headers and handle chunking yourself. That's actually not so hard though. For cross platform SSL you just need to use Open SSL which is actually pretty simple in C++.

Basically if you want really fine control of your network streams or are using things other than just HTTP then ASIO is going to be what you want. If you just want to have something handle HTTP for you then there's quite a few other libraries out there you can choose from.

I'd say not only would windows be nice but the option to take down the roof as well.

Of course I enjoy driving far too much to ever give that up to an automated vehicle. I've been keeping a spider (MR-S) for a while because I really enjoy driving with the roof down. And even though the MR-S is used and beat up and mostly stock I keep it despite the fact my primary vehicle is a tuned GT86 just because it's a blast to drive an MR with the roof down.

If you ask me all these people who are pushing for automated cars should drive an 86/BRZ or an S660 or a Lotus or some other drivers car and see if they reconsider wanting to get rid of the "hassle" of driving. Don't get me wrong; certain automation can be good (EG: Subaru EyeSight) but at the end of the day the actual act of driving should be something enjoyable.

MS is deploying agents to give you a Mountain Dew enema and throw Doritos dust in your face until you repent, blasphemer!

They also closed-sourced all the things they had open-sourced. I got one JUST before they did that and I've been not-so-happy with it ever since.

They betrayed "makers", open source, and their customers. They deserve a worse fate.

I only paid one-way shipping on the RMA, which wasn't so much. You had to pay to get yours fixed/replaced?

While your genaralization of GoPro users is probably over 90% accurate they are actually amazingly good action cameras. I use one myself for a variety of motorsports. Eg:
https://www.youtube.com/watch?...
Carting requires you to find the fastest line around a course. I use the GoPro video and check my lap times with different lines. What's great about it is the video is very clean - the GoPro has extra processing hardware that cleans up jitters and keeps the colors clean whereas a normal video camera you'll get a blurry mess.

I'm really not sure how secure you need to keep these things either. The WiFi is really only to control the camera or grab files off of it over the air so I really could care less if someone got the auth credentials to mine.

I wonder if they have improved. I got a Hero 3+ Black which had issues in very cold weather - I sent one e-mail, they sent me an RMA form, I sent it out and a week later had a brand new unit. This was maybe 5 months ago - so fairly recent; and it was with support in east Asia so it could be a difference between support teams as well.

BTW don't discredit accusations of a bad SD card - I've had a few SD cards go bad on me that caused some crazy issues including me bricking a Zaurus during a firmware update.

Until you framed the context here I actually hadn't realized what the motivation for designing systemd like that could have been. As you've pointed out; while that mentality of hard-coding all these modules into pretty-little uniformly shaped candy shells will be super convient to deploy a few thousand disposable server instances it's going to make any hand-tuning a big pain in the ass.

The fact that one of the "sale points" of systemd is to have these localized initialization modules included in packages just re-inforces your point - and it makes me worry systemd is going to replace any customized modules each time a package is updated. Ugh.

This is the most insightful comment in this entire discussion. It's nested pretty deep though - maybe you should copy this and paste it as a new post. People need to see this.

Again, I don't hate him. I'm just curious as to why you defend him so much. And by "relationship" I mean do you know him? Have you worked with him? Have you been involved in the technical discussions his negative image arose from? I wasn't implying anything else... So why are you so bent on defending him?

> and using that hate in place of technical considerations
I think the problem here is a lot of the "hate" he's getting is from *him* ignoring technical criticism. At least that's what a lot of people have pointed out. He kind of projects this attitude of "I'm right because I know I'm right and my way is better" which is an extermely frightening considering how much of an integral and low level component of the system systemd is.

As developers we need to take criticism seriously. When someone says "I think this is wrong" or "I'm worried about this in this situation" or "Do you think this is really a good idea?" it is quite possible they may have noticed something we've overlooked or failed to consider.