I don't think this case follows the usual story of "person reports vulnerability and is punished for it". See my other comment for details and a link:
731 karma · joined March 16, 2015
https://www.vice.com/en_us/article/59nzjz/teen-security-rese...
This article has more details about the reasons Demirkapi was suspended. Apparently he first tried to contact Follett (the software maker) directly, but they ignored him. He then tried to use the software itself to send a message Follett, but the message was instead broadcast to a large number of parents, teachers, and administrators across the district. This does seem pretty irresponsible, and Demirkapi said he understood the reason for his suspension.
Thus, this doesn't seem like the usual "person reports vulnerability and is punished for it" story.
Of course the ultimate responsibility lies with the software makers who have these vulnerabilities in their software and who don't respond when someone reports them.
By default, the OpenJDK builds put something obvious like “-internal” into the version string, and you have to override it explicitly if you are intending to produce an official build. Whoever made these builds overrode the version string to make them look like official releases, when in fact they don’t correspond to official release tags in the source.
In other cases there may have been a delay between the appearance of an official binary and the appearance of the release tag in the source tree, but that’s not the issue here.
Unlike the rear-facing camera, the front-facing camera does not have an IR filter and can easily pick up IR lights in the dark.
To try this at home, grab your TV remote, which uses IR light to send information to your TV and open the front-facing camera on your phone. Next, point the front end of the remote at the camera and press any of the remote buttons. The IR light that is normally not visible will be completely visible on your camera screen.
Well I’ll be darned. This works! (iPhone 7)
The JDK sources were maintained in SCCS (which was wrapped within CodeManager/Teamware) prior to being open sourced in 2007. The history in the OpenJDK repositories goes only back to that time. The (Oracle internal) archives of previous versions of the JDK, which date to before JDK 1.0, are still in SCCS format. I'll occasionally browse through the ancient history of these sources using Schily's SCCS implementation. What's cool is that all my old shell aliases and functions still work. Of course this is browsing/viewing only. I haven't checked in an edit using SCCS in decades.
We used SCCS on a shared filesystem. If you really needed to edit a file somebody else had locked, you simply removed the lock file. Of course, social convention was that you better have a really good reason for doing that. If you went on vacation with files locked, it was pretty much expected that your locks would be removed, and that you'd have to merge or otherwise deal with your stranded edits.
> Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.
Weinberg’s books are filled with named “laws”, so many that some of his books have an appendix that lists them all. Here’s one of my favorites:
> Boulding’s Backward Basis: Things are the way they are because they got that way.
[Quality Software Management, Vol. 1: Systems Thinking]
Edit: FWIW, I looked through the history, and it looks like Thread.destroy() was added by Bill Joy in Aug 1995. The initial implementation was "throw new NoSuchMethodError();".
On the other hand, sometimes other people never transcended those bad habits from BASIC. Sometimes you run across programs that are one big function, with variables reused, etc. I don't know what the thought processes are of programmers who write such code. There's an old saw, "You can write FORTRAN in any language." Maybe this should be applied to BASIC as well. That's probably what Dijkstra was driving at. I don't know about "mental mutilation" (certainly hyperbole, in my book) but only Dijkstra knows what he really meant.
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EW...
At least, the "mentally mutilated" phrase is about BASIC. The "criminal offence" phrase was actually about COBOL. You'll note that Dijkstra also had choice words about FORTRAN, APL, and PL/I, which were popular programming languages of the day.
It's tempting to say that Dijkstra was being tongue-in-cheek when he wrote this. I never met him, but based the attitude I picked up from his other writings, I'd guess that if you had asked him he'd have said he was completely serious.
And he has a point. I first learned programming in BASIC, and look how I turned out. (Well maybe I confirm Dijkstra's point. Others will have to judge.) But I do recall a bunch of characteristics of early BASIC systems that potentially led to terrible programming habits: GOTO and line numbers leading to spaghetti code; all global variables; no scope; no functions; self-modifying code (overlays); etc. All of these had to be unlearned at some point.
Oddly, that's one I had memorized. It actually stands for PC Memory Card International Association. (That one I didn't memorize; I had to look it up.)
1) There's a lot of value in writing down something about one's experiences, even if the result is "obvious" to anyone else who has gone through the experience. There are likely a lot of people who HAVEN'T gone through that experience who would benefit from reading about it.
2) I worked on a project, mostly independently, for a year or so and produced something useful. To me, it seemed fairly pedestrian: some basic data structures, some ordinary algorithms, nothing particularly novel. A mentor suggested I write a conference proposal about it. I resisted, using the "it's obvious" argument. He came back and said "You've worked on this for a year, and no one else in the industry has worked on it. By definition you're the expert. It's worth a conference talk." Indeed it was, and it launched a significant portion of my career as a conference presenter.
I think this is largely about the difficulty of thinking about what others think when one is too close to a topic. After working on something intensively for a time, one develops a familiarity and intuition of the knowledge about that area. When working with that understanding, things may seem "obvious" but that are totally non-obvious to someone who hasn't worked in the area. This is less about absolute intelligence per se than it is about expertise, and so it's a variation of Kay's aphorism "A change in perspective is worth 80 IQ points."
http://www.npr.org/2017/07/31/540515367/familiar-looking-num...
One thing that this doesn't mention, but which I heard somewhere, is don't call that number back and ask "Why did you call me?" In case it isn't obvious, the caller IDs are spoofed using random numbers, and the person who has the number listed doesn't know their number is being used this way.
One amusing anecdote from the NPR piece is the person who received a call with a caller ID of ... their own phone number!
XRotateBuffers is implemented using the RotateProperties protocol request, which given a list of property names, will rotate their contents by a given number of places as if the list were circular. This same operation could be done using a sequence of other protocol requests like GetProperty and ChangeProperty. The problem with doing that, though, is that another client attempting to perform the same operation at the same time could have its requests interleaved arbitrarily, leading to corruption or other errors. Each request is performed atomically, so a single request RotateProperties needed to be added to the protocol in order for the rotation operation to be performed safely.
[1] https://www.x.org/releases/X11R7.6/doc/xproto/x11protocol.tx... ; search for "RotateProperties"
It did help confirm a sneaking suspicion I've had, which is that robocalls spoof a caller ID number with your area code and prefix, to make it seem more familiar.
Stories about people who manipulate telemarketers are amusing, and mobile minutes are mostly no longer scarce, but who has the time? Time and attention are the scarcest resources.