How dangerous can this be in the wrong hands? Seems like it can significantly lower the barrier to entry for someone wanting to gain unauthorised access to many buildings that use remotes or RFID for access control.
>If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.
I’m not a friend of RMS, although we have argued over email.
RMS has a unique super power I propose you admire: he is deeply committed to his convictions, and willing to construct his life around them.
He has autism so he finds himself in situations that you are politely calling tone deaf a lot; he has said in public that he can find the responses hurtful. But he still keeps on with his values, at times at great personal cost.
I think of him as a sort of national treasure; if we had 10 of him in the last twenty years the world would be a much better place.
I agree somewhat; having had dinner with him once with our local Linux organization when he was in our part of the world over 20 years ago, I think I learned a lot in that short time.
What I came away with was that SOMEONE needs to hold the points of view that he holds, at least as far as they pertain to software development and licensing, since almost nobody else does.
Whether he presents as well as he could is a different matter. The recently reported on comments he has made could and will be perceived as quite distasteful.
I greatly admire many if his achievements. My comment is that I'm surprised that he was able to be so successful while many times taking a position so at odds with a sentiment held by most of society. My opinion is that "picking your battles" seems to be a more successful strategy in general. I'm also not commenting on the ethics of being flexible about your convictions and how you express them.
> But he still keeps on with his values, at times at great personal cost.
Until it's too inconvenient. He's said previously that he doesn't own a mobile (cell) phone - but will use someone else's.
He's the tech equivalent of a fucking anti-vaxxer. Doesn't want to deal with the realities and compromises of having convenient communications, but happy to ride on someone else's compromise for his own benefit.
> I think of him as a sort of national treasure
A man who wants pedophilia, child porn, bestiality and necrophilia legalised, is "a national treasure"?
I don't even want to know what nation you think should treasure people like that.
I looked up a definition of "tone deaf" to see if I misunderstood in my interpretation of the term and how I used it above.
>having or showing an obtuse insensitivity or lack of perception particularly in matters of public sentiment, opinion, or taste
Having read that I stand by what I said. In my opinion he has shown "an obtuse insensitivity or lack of perception of public sentiment" on more than one occasion. The Minsky message being a very good example. Whether you agree with the sentiment or not is seperate from clearly being obtusely insensitive about the public sentiment I think.
No one is questioning his book smarts or ability to perceive auditory sounds. But, like, learn how to read the room, man.
He waded into the crazy internet morass that is sexual assault and Epstein, and didn't realize that quotes like the one below might trigger a response. That is either hopelessly naive, or absolutely "tone deaf" -- these have been over-the-top, hyper-sensitive topics for weeks.
Maybe he's just so used to staking odd or controversial positions and didn't see this as any different, I don't know. But the optics are terrible.
> "The most plausible scenario is that she presented herself to him as entirely willing," Stallman wrote in his post last Wednesday. "Assuming she was being coerced by Epstein, he would have had every reason to tell her to conceal that from most of his associates. I’ve concluded from various examples of accusation inflation that it is absolutely wrong to use the term 'sexual assault' in an accusation."
And yet, people are concluding from that quote that he "loves rape", which is so wildly different from what he is actually saying that I have to wonder if people even read his words.
It seems to me the problem isn't that he's tone deaf but that other people have terrible reading comprehension.
"To avoid schedule slippage, game developers
need to spend more time to plan out all the work that
needs to be done so that no tasks are overlooked when giving
estimates. By planning out tasks, you can also estimate
each task individually, and give a more accurate prediction,
instead of an optimistic one."
When things don't work out according to the schedule, there are generally two reactions :
1. We didn't estimate well enough, we need to estimate better next time.
2. Maybe this estimation thing is impossible to get right, let's not put too much trust in being able to estimate accurately, but rather find ways of working that don't require estimating all work up front.
I've seen that 1 gradually becomes 2 with experience (the experience of getting the estimates wrong every time).
so true. the estimation game can work well on time scales of up to a few months (like 2 or 3)... maybe
anything beyond that scale becomes the educated guessing game. no amount of analysis can flesh out every blocker that will be encountered. the deeper you go analyzing each task, the more the work just becomes doing that task.
In a perfect world, it works as other comments point out: you get better at it, and everything is wonderful.
In real life, that estimate you gave last week becomes your duty. Unless you pinpointed it, you're out of schedule. If you're late, you look bad. If you're early, you get more work next time.
And there is no good way out, you can do it poorly but in time (which will only compound time as your poor solutions will introduce more work).
You can do it late but good (but, well, late).
You can give stupidly high estimates and then make your own secret schedule (and get found out eventually).
Agile is Fordism.
My advice: do not estimate timings. Have a list of things TODO, and have someone monitor expectations.
Here's the problem I keep coming back to with task estimation for implementing software. This is the absolute minimum description of what a software engineer's responsibilities are: Giving the correct set of instructions to a computer about how to accomplish a task.
Given that, a precise understanding of the time involved to accomplish a task requires knowledge of the time it takes to come up with the correct instructions + the time it takes to give the correct instructions to the computer. The time cost to give instructions to a computer is effectively linear in the size of those instructions (its whatever my typing speed is times that size), but the time cost to understand what those instructions need to be is effectively unknowable unless I've already got those instructions. It's sort of like the halting problem for people... if I knew how long it would take to come up with a reasonably precise version of them, you'd have a version of those instructions that could execute in some language (say some imaginary pseudocode language), or I'd have determined that the task is impossible.
I can keep a heuristic understanding of how long a task will take based on previous tasks I've completed (i.e. this task sounds similar to this previous one, which took me this long. I'll use that for my estimate), but there will always be some set of tasks for which I'm wildly wrong unless I precisely examine what's involved.
If it's better to estimate in a fashion such that I deliver everything I promise (and that we can have a planning session that doesn't last the entire sprint), I can pad my estimate by a large factor. In general, its easier to meet the criteria for this situation, but there will still be tasks for which my estimate can be wildly off. This can also lead to unhappy product owners who assume I'm trying to rig planning to excuse less work.
How do you come out of this exercise unscathed and with valuable information?
I think you're talking about "first year of work" levels of experience.
Estimation is hard - but a major goal of Agile development is to make it possible.
How does that possibly solve the problem being discussed here? Are you the god who can define ALL tasks (in the agile meaning, a sprint consisting of a number of tasks) that a large project consists of up front, all the way to the end of the project 3 years later (for example)? Agile delivers because it doesn't attempt the impossible.
The problem seems to be that although companies want to pretend that they are all agile, the business and planning side really is not, because resources are not unlimited. So if you can't (even if admitting that it's faulty) put a number on time and effort, someone else higher up the ladder will do, and then it will hurt you.
I think that toolchains should have better support for estimated vs used time and then learning from that. You could classify tasks by field (DB, frontend, etc) and then calculate correction values based on past failures. Learning from wrong estimates seems to be even harder than estimating, because it hurts to admit that you were wrong, so some automated, blame-less version of it (per sprint or so) might be a good start.
The tricky part is that agile is supposed to help those people sleep better. But it all kind of depends on your ability to explain to them how agile does that.
Of course budgets and deadlines has to be set. Agile is not a way to ban those, it's a way to allow them, even if forecasting is impossible. It's about saying, well at that date I can promise to have kept under budget, and will have something that more or less reaches the goal of the budget. It will not, however, be what anyone is imagining right now, let's have fun discovering what it'll be.
My response was to optforfon's comment... I don't see how your response fits in in that context. optforfon's claim seems to be that Agile fixes the planning problem - which it doesn't, it simply limits planning to that which is plannable and (much more) easily foreseeable - small tasks right in front of us.
> 2. Maybe this estimation thing is impossible to get right, let's not put too much trust in being able to estimate accurately, but rather find ways of working that don't require estimating all work up front.
Isn't agile the #2 option quoted above? Agile in game development means being able to estimate how long it'll take to add fire damage to a weapon. It's not a means of being able to budget out 3 years worth of development, let alone hit a shipping date that far out.
I agree Agile is the way to address many of these issues. I think Agile is a way of working that doesn't try to estimate everything up front. Rather one or 2 short iterations at a time. If you're trying to estimate your whole backlog up front when you do Agile, you're back to waterfall realy.
Polymorph | Cape Town, South Africa | Full-Time | Remote but in South Africa prefered.
Senior iOS (Swift) Developer
We're a company with a remote first culture, building mobile products for startups and enterprises in Fintech and IoT. We have clients all over the world.
Interested in working for a company in one of the best cities in the world in terms of natural beauty, food, things to do and cost of living[1]? Mail us at {info at polymorph dot co dot za}
On iPhone the problem was that FB left a bug (according to FB) in the application which made it play silent audio in background. Incidentally this meant that the app was able to bypass the iOS restrictions on background processes.
Whether it really was a bug or intentional is a subject of debate though.
On iOS your application can not stay fully active for more than 10 minutes. After that time it gets into suspended state and can be waken up only when it receives a notification (and the wake up time also has time limitations). There are only three exceptions to this rule: active GPS usage for maps and trackers, active voice calling apps (for ringing) and music apps that are actually playing audio. Silent audio thus enables Facebook to stay alive forever.
This had also the effect that when you were listening to music or a podcast and opened the FB app it would stop playing your audio.
