I originally misread the summary, assuming this had to be a non-stop thing, then quickly realized that's not what they said, and the 2 pilots 1 seat stood out a lot too.

So, I agree... how is this an interesting technical achievement? Given enough time, they could throw a paper airplane around the world, or fly a glider around the world. At this point, "around the world" only seems interesting to me if it's non-stop or human powered (ex. walk around the world).

I thought this was meant to be a joke. Then I looked at the list of suggested ideas, and this is the second one:
Project: Port KSystemLog to use journald as a backend
https://community.kde.org/GSoC...

Granted, I didn't see any others in the large number of other suggestions. Still a bit of a coincidence.

The bug report linked by kolbe (https://bugs.freedesktop.org/show_bug.cgi?id=64116) is, IMO, a very good read to give a quick glimpse of the fine lines between the two camps (pro-systemd; anti-systemd).

Poettering's first reply/answer was simple, "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence."

That embodies the "here's a bug; our answer is to say it's a feature and not a bug; NOFIX" that some people feel.

He then follows it up with a much longer reply because, "Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd". I'm not quoting out of context - that's the first sentence of his reply. Regardless of the motivation to his reply, the reply was much more thorough and he seems to truly want to help others understand. IE. I think it shows some of the good side there.

However, I'm still anti camp, and I'm not there because bugs like this are not directly fixed. I'm anti because of the underlying assumptions that are needed in order for his reasoning to be justified. In this case, that reasoning only works if one assumes the need for a binary log whose format includes re-writable parts at the front of the file, and whose corruption results in an non-repairable state. However, if the format is such that, after corruption, it's difficult or impossible to fix, why are they using that format?

FWIW, that specific bug report was, "How does one fix journal corruptions?". In that context,his answer is completely sufficient - you don't. The next question seems obvious to me though - how do we avoid that in the future? Currently, it seems that the systemd solution is to make the log reader more intelligent so that it can handle the corruption, like an FSCK, and read as much as it can.

Personally, I'm really hoping that uselessd matures and becomes commonplace and easy to drop in. It's not ideal, but it seems that systemd is going to be everywhere through the Linux community, and there's no good way to avoid that at this time. Uselessd would at least allow someone to use alternative init systems while still being able to use modern applications and environments without crippling them. Regardless of ones opinions on systemd and other init systems, the ability to swap out a subsystem is something that we should all be able to recognize as valuable.

Learn to use google or wikipedia, or follow the link I had in my comment. What you're talking about is referred to as "swatting", as in tricking emergency services into dispatching the swat team to someones house.
Swatting: http://en.wikipedia.org/wiki/S...
Doxing: http://en.wikipedia.org/wiki/D...

You are correct. I used the wrong word. I believe a more appropriate word would have been "Homicide", which is simply to cause the death of another human being, whereas "murder" and "manslaughter" are types of homicide.

My point stands though, so thanks for correcting me, and a big FU to the AC's yelling STFU and contributing nothing of value to the topic.

Get used to it, cause doxing refers to what's done, not the motivation. For example, "murder" is someone kills someone else, be it by accident, pre-mediated, etc.

In addition, whe he did falls entirely within the current definition of doxing (http://en.wikipedia.org/wiki/Doxing). IE:

The very first method is searching publicly available information!

"Innocent victims of doxing"... is that supposed to be like "but think of the children!" Doxing is what it is. Whether the result is good or bad is subjective and unrelated to the definition of doxing.

My question/concern is, which sub-project will they kill off first? I'm betting streams will be dead/abandoned in a year or two.

I picked a really poor phrase there. See the comment one above mine: "I know I've seen systems that use sensors you mount around the edge of a whiteboard and special markers to track where you are drawing and reproduce it electronically on remote monitors"

In those cases, they are one way systems. You can setup another going the other direction, but it's not a shared whiteboard. The remote end can't tell your markers to draw on your board.

There are ones that use a projector and fake makers (ie. a marker shapped IR LED), but then the orig question fully applies - what do you use? There are certain makes/models of these things, and they are often incompatible.

Maybe most people don't care, but there are many very very good reasons to have this feature.
My personal favorite is that, with recent android builds, you can no longer plug your phone in and have it show up as a mass storage device (without rooting/etc). If you want to actually access the filesystem where your data is stored, then you have to take out the SD card and use a reader - at least that workaround is available.

The z10 is actually thinner than an iPhone 4 or 4s, neither of which had removable batteries.
The iPhone 5 is only 0.3mm thinner than the Samsung Galaxy S4, which had a removable batter.

I was curious of the general size comparisons regarding thickness, so I looked these up:

Samsung Galaxy S6 edge : 7 mm
Samsung Galaxy S6 : 6.8 mm
Samsung Galaxy S5 : 8.1 mm
Samsung Galaxy S4 : 7.9 mm
Samsung Galaxy S3 : 7.6 mm (CDMA for verizon or sprint)
Samsung Galaxy S3 : 8.6 mm (GSM/others)

iPhone 6 Plus : 7.1 mm
iPhone 6 : 6.9 mm
iPhone 5 : 7.6 mm (same for 5s)
iPhone 4 : 9.3 mm (same for 4s)

Blackberry Z3 : 9.3 mm
Blackberry Z30 : 9.4 mm
Blackberry Z10 : 9 mm

Motorola Moto X : 10 mm
HTC One - M9 : 9.6 mm
HTC One - E8 : 9.9 mm
LG G3 : 8.9 mm
Nexus 6 : 10.1 mm
Lumia 635 : 9.2 mm
Lumia 532 : 11.6 mm

Maybe using a non-removable battery made it possible fore Samsung to go a little thinner, but it's very little on something that's already quite thin. I'd suspect the restriction has more to do with other things, or at least a combo of reasons, such as:
* having no sd card support meant access to that was not needed
* water/dust proofing is a lot easier if the back is not user serviceable
* move to metal frame probably brought some limitations (or challenges). The old plastic backs were simple to pop off/on without (much) damage.

I'm sure they had their reasons. I'm also sure that I'd rather have SD card support and an easily replaceable battery. However, if the feature in balance were waterproofing, I could be convinced to give up the battery and sd card.

Seriously? Digital whiteboard? How does the other side touch it?

In this day and age of tablet ubiquity, it's the ONE THING they should be nailing perfectly. There should be a couple "standard" protocols or apps for this (though I won't hold my breath... the main text chat clients/protocols don't interoperate, so who would expect anything more complicated to work).

Every time I go to look for a whiteboard solution (networked and multi-user), I'm amazed that the old solutions are no longer around, and there's new solutions, and the places that I'd expect to have grown to cover this feature (existing and popular chat clients like pidgin, skype, hangouts, jitsi, etc) still don't have it.

The direct answer to TFS's question is not all that interesting. Why it's not an obvious couple answers is, IMO, interesting/peculiar.

Hate replying to myself, but I hadn't RTFA before posting. I'm not entirely against what they're saying/proposing. It's a different way to do things, rather than just some folks whining and complaining and avoiding estimates for stupid reasons.

Holy crap! Are people actually buying into this BS?

WTF? Yes, you can give an ESTIMATE on how long it'll take to solve a maze. Go get a book of mazes; Do 10 of them; Time yourself for each one; You now have min, max, and average times for a maze of that size/complexity. Next time someone shows you a maze, you can make an educated guess about how large/complex it is, then give your best case, worst case, and normal/average estimates. Do the same for programming.

They're also good for creative tasks. I went to college with a major in fine art and worked for years as a monument engraver (etching portraits/landscapes/etc on tombstones). If someone asked about how long it'd take to etc a 5x7 portrait, I'd have a VERY accurate estimate for them. Is that not creative enough for you? How about every single project for every single class for every year of art school? ALL of those had timelines, and every student became quite good at estimating how long each project would take so they could get them all done on time. And you could ask most of them (at least those with higher than a B average) how long it would take them to do a certain thing (ex. sculpt a bust in clay from a live model) and, if they were familiar with that medium, then they could give you a very good estimate.

If management is asking the devs for their estimate, then how in the hell is it management fault for any of those timelines? Let me put this another way... devs, BE SMARTER. You've been asked for estimates on more than one occasion. Most that are new to development will low ball (stating a best case estimate). If/When you do that, you're just setting yourself up to fail. The best outcome will be that you are on time, and every other outcome sucks for all involved.

If you're not good at estimating, just try, come up with your figure,then double or triple it. If you always come in under the estimate, then you manager may start adjusting your estimates... who cares? Let them. It's their fault if you don't meet their manipulated figure. However, if you're not giving a large enough estimate in order to get your work done, then it is YOUR FAULT if you fail to hit your own estimate!

All that said, there are cases where providing an estimate is unreasonable. On one end of the scale, if a manager is asking for very accurate down-to-the-hour estimates on vague but somewhat small tasks, then it's asking for too much (almost more work estimating doing the damn thing). On the other end of the scale, if it's some grand idea for a giant project with no plan yet, you'll be pulling figures from your ass just as much as he's pulling the project plan out his ass... but it is what it is. Just go big.

A lot of it is just about setting expectations. If you give them high estimates, then you're more likely to meet or exceed their expectations. They may dislike the figure at first, but when you come in under budget they will be very happy and forget all about how high the estimate started out. A high estimate is not "padding", it's setting expectations that you can meet (see the maze estimate above... use "max" and you'll be able to meet or beat your estimate every time, which is what all involved really want out of your estimate).

There was a lot of great stuff in it. ActionScript was WAY ahead of javascript for a long time, implementing fairly cutting edge ECMAScript.
The old interface was very simple and very easy to use with keyframes and animation and sound syncing etc etc... if that's what you wanted to make, it was pretty great.

It grew into that, and really only once it was abused in awful ways. Simple stuff used very little CPU, and by that I mean P133 level CPU could handle it just fine.

IMO, the single biggest factor / thing that should have been done different : the plugin/player should have been open sourced. I'm not going to claim it would have solved all their problems, but things like dragging their feet on 64bit support for YEARS would have been solved, and I'm sure it would have got some assistance in other ways, and probably some forks for good measure, and wider platform support. DRM is a large part of why this didn't happen, and it's the second thing I would have change (they shouldn't have including that in it; let someone else implement that in actionscript and add some way to optimize actionscript better, for example).

On the HTML5 side, we're re-living some of the same mistakes. Where's the easy to use controls for what a page can do, and what I can dynamically enable/disable?

The only reason adblock (and similar) work is because ads are still counting impressions the same way they always have. It's be easy to change that technically by either:
a) deliver the ads proxied through the site, so they are sourced from the same IP.
b) deliver the site through the ad network. IE. treat the ad provider as a CDN and deliver the entire page content through it, and let them integrate the ads.

"a" would make impressions difficult to track (no secure way to do so).
"b" would require site operators to give up more control, but they'd also gain a CDN for free, and they could use that for caching as well to greatly reduce their own bandwidth. I don't know why this hasn't been tried.

In any case, we need proper controls, not filters.

FTFY. Also, It'd void your warranty and trigger the liquid contact indicators.