Domain: usenix.org
Stories and comments across the archive that link to usenix.org.
Comments · 571
-
Re:I hope Apple fixes bufferbloat in LTE & 5G
8 years of R&D and having fixed wifi thoroughly with work shipping in both linux and OSX? BQL+ RFC8290/fq _codel for ethernet , SQM/or sch_cake for linux on cable, dsl & fiber, fq_codel + ATF for wifi: https://www.usenix.org/system/... In wifi, now, at least, uplinks are easily controlled at the user device (phone), which is what I was mostly measuring. Same principles apply to lte and 5g. In lte, for downlinks, you need help at the enode b and backhaul. Those suck too, but "only" to about 600ms max latency under load. https://www.ericsson.com/en/er...
-
hah, amazon copy-catted me
my wifi lab is located deep in the los gatos hills, in a naturist colony and 110 acre campground called lupin lodge. Luckily I was not fiddling with new frequencies and stuff that required FCC approval, because, well... suits aren't welcome here, and there's essentially no dress code. Wifi's pretty good, though... ( https://www.usenix.org/system/... )
-
Re:Support for a 5-year-old iPhone?
I agree also. Had Motorola phones, they run almost vanilla Android. However, after a year they get forgotten about. It is not the lack of new features that necessarily irks me, it is they never release security updates. There are some very bad malware out there, latest problems with 'disk in the middle' attacks, and the latest attacks using AT commands https://www.usenix.org/confere... are scary! Wil Android hardware manufacturers update their devices, maybe Google and Samsung, the rest maybe not.
-
Paper about the Huygens protocol
The New York Time article is mostly about how Nasdaq is eager to make more money.
For the technically minded, refer to the paper about the introduced Huygens protocol for network time synchronization precise to the nanosecond.
-
Re:"I bet they were instructed to ignore the risk"
That's bullshit. When Intel introduced speculation across protection domains everyone including Linux was happy because it reduced system call costs.
And I'd be happy too if you were selling me beef at $0.50/pound. Even if you told me you weren't washing out the containers every single time and those sorts of time savings were why the beef were so cheap. Until, of course, it turns out that people weren't washing their hands and failing to wear gloves all the time.
We've known for a long time that side channels of this kind were possible, but not that they were performant. The new attacks are not interesting because they're side channels that allow data to be disclosed, they're interesting because they're side channels that allow disclosure far faster than previously believed.
And this is the issue. Cryptography experts routinely speak of cryptographic schemes being insecure well before attacks on them are performant. It's understood that it's likely someone will come up with a more effective attack within a couple dozen years likely on at least *some* of the potential vectors of attack which will render at least *some* of those cryptographic schemes no longer valid, so it's better to move away from those schemes now. So, even if we were to acknowledge what you're saying, it stands to reason that once those papers were published (a quick google search and there's papers about effective cache attacks from at least 2013) that changes should been made then. Instead, ARM, AMD, and Intel all waited until a performant attack exists and then there's a scramble to try to find fixes and workarounds.
PS - STEALTHMEM: System-Level Protection Against Cache-Based Side Channel Attacks in the Cloud from 2012 and it sounds like much better performance costs compared to KAISER, although not being a security researcher I have no idea if this would be sufficiently to protest against speculative execution as well.
-
Re: This is the attitude of many security experts
It's way too easy for someone to sneak in an extra box of fake ballots to rig an election.
It's hard to rig an election with a single box of fake ballots. It's also hard to bring in thousands of boxes without anybody noticing.
In addition, cryptographic security researchers have constructed a cost-effective, scalable, paper ballot system which makes this sort of fraud (and others) detectable.
Paper, backstopped with math, is unquestionably the most fraud-resistant way to conduct elections. Pure electronic voting systems are perhaps the best way to enable fraud.
There is a valid argument for the use of electronic voting machines for accessibility. Large touch screens are easier to use, especially for people with disabilities, but they should merely be an interface to collect information for printing on a human-readable paper ballot.
I'm both a computer scientist and a computer security expert. I think you'd be hard-pressed to find anyone who understands computer security who would honestly support direct recording electronic voting.
-
Do you need an OS?
“We have a whole valley full of people talking UNIX versus MS-DOS. What do you need any of that for? Just throw it all out; get rid of all that nonsense. Maybe you need it for computer scientists, but for people who want to get something done, no. Do you need an operating system? No.”
– Jef Raskin -
Re:Manual counting only in Norway last night
It's an interesting exercise to try to solve these problems, no doubt. However, we actually have a couple of decades of serious academic research into these problems, and they're pretty well solved. You should read the Scantegrity paper: http://www.usenix.org/event/ev.... It's not the last word, I'm sure, but it's extremely good, and eminently practical.
-
Re:Manual counting only in Norway last night
I'm not sure what "other schemes" you're referring to.
The ones listed as anonymizing at the end of the Wikipedia article you referenced. At this point, I don't know quite what you're talking about.
Until/unless you read the paper, we can't really communicate about this effectively. It's linked from the Wikipedia article, but I'll provide it here as well: http://www.usenix.org/event/ev...
If it's the idea about having lists of candidates by letter, and varied orders on the ballot
It's not. You can either vary orders on the ballots or not. Makes no difference to this system, and voters mark their ballots by filling in the bubble next to their selection, so there's no unusual opportunity for confusion.
The scheme to fool the bribers and/or threateners appears to be to fill out several ballots, vote with one, and keep all the receipts. Again, that complicates the voting process.
That would not provide any way to either inform or fool bribers and/or threateners. All the ballots are different and showing multiples would change nothing.
Hand-counting the vote becomes immensely more difficult. Rather than just going through ballots and seeing which candidate was chosen for each, each ballot has to be looked up, and the lookup process has to be secure.
No, it doesn't. Ballots can be hand-counted just by looking at bubbles next to names.
-
Re: Linus Wins Again
-
Re:why?
You should read through this and see if you can adopt any of the methods mentioned to eliminate lost data in the container completely.
https://www.usenix.org/legacy/... -
Re:Frist psot
Anyone who wants to recommend either GPG or PGP should have read and should give a good answer to both of the following articles.
And you should include hello to avoid the issues mentioned if you are making a recommendation.
-
Re:Not possible
Malware is completely unnecessary here. "Direct detection" is a term defined on page 2 of Challenges and Directions for Monitoring P2P File Sharing Networks – or – Why My Printer Received a DMCA Takedown Notice to be:
"involves connecting to a peer reported by the tracker and then exchanging data with that peer" As opposed to:
"Indirect Detection of infringing users relies on the set of peers returned by the coordinating tracker only, treating this list as authoritative as to whether or not IPs are actually exchanging data within the swarm."
The indirect detection method only shows that a specified IP address was connected to the torrent swarm for the file in questions but it does not prove that particular IP address was sending any bits to the other peers. -
Re:microphone
Check this paper..., and you'll be even more worried.
-
Re:Strange flamebait article
L4 and QNX are nice, but do you have an example of their use outside of the embedded space?
L4Linux, ie. Linux running on L4 as a guest, came out before Xen and paravirtualization was even a thing. The overhead of running on L4 was demonstrably lower than Xen. So you could run L4 on a desktop using Linux as a guest. Maybe you still can, though the Linux kernel is probably quite outdated now.
Context-switching overhead has always been the argument against microkernels
It's substantially better than hypervisors which are now everywhere.
So basically, despite their fancy message passing design, to get performance they have to lump everything together into gigantic monolithic applications, albeit running in userspace. Doesn't sound like a great proof-of-principle design to me.
QNX was and is typically deployed in embedded systems where resource constraints dominate. These are domains where you'd use something like the lwIP library embedded directly in your application to get a networking stack. These certainly aren't representative of desktop or server systems, which is presumably what you're asking about.
Furthermore, there's no question that achieving high performance in a decomposed design with lots of isolation boundaries is harder, particularly if you want to achieve security or other properties, which is where researchers mostly focus, but it was solved at least 12 years ago. If a final release wants to squeeze out that extra 2-5% of throughput, you can switch a compile-time option to link everything monolithically, but that doesn't mean you should design it monolithically by default.
Microkernel "performance issues" are largely a myth. The very first microkernels in the 80s had some issues due to their design, and simple profiling identified IPC as the problem. Liedtke then invented the L3 microkernel that solved this problem, and there has never since been an informed performance complaint against microkernels. This myth persists due to that initial impression and to developers looking at the structure of this system and simply saying, "well obviously this will be much slower". Not very scientific. Past research is why microkernel papers focus on IPC; it's just science in action.
Finally, the KeyKOS operating system was a high-security microkernel design that was widely deployed in commercial timesharing systems, and even early ATMs, back in the 70s and 80s. It was proprietary and unpublished until later, and included hard disk drivers in the kernel because its core design included orthogonal persistence and the verifiable security properties depended on an audited disk driver. Other than that it was a legit microkernel and hosted an optional full POSIX guest.
-
Re:How does injecting a cookie expose data?
There's a paper if you're interested in the details.
-
Re:How does injecting a cookie expose data?
Read this USENIX paper for specific implementations demonstrating attacks using this vuln.
-
Re:i think it shows trends in GitHub's demographic
The rant on new (the stanford paper) was not mine. And, it was about new being an operator instead of a function. BTW, I've been programming in C for 35 years (+ 10 before doing C). I haven't seen malloc use char * in at least 15. And why does one need to use std::unique_ptr to force C++ not to be "cute"?
The RTTI is disallowed at Google and C++ is their goto language. It's also slow. There was a recent usenix paper https://www.usenix.org/confere... that has a CaVer tool for detecting bad downcasts. It does much of what the RTTI does but as a tool. It could easily be adapted into an alternate RTTI implementation and it's much faster than RTTI (e.g. it uses RB trees instead of walking the hierarchy with string compares)
C++ makes code easier to write, but because it's easy to abuse, it's harder to review/debug. Because, you have to detect the abuse, which can be much harder. Particularly when you have to peruse 50,000 lines of code to get the first clue as to the bug.
Inheritance does violate encapsulation. See a better example I did here: http://slashdot.org/comments.p... You're assuming you control the superclass instead of just inheriting from it. That is, the author of X and Z are the same programmer, or even in the same organization. Read that post, especially the timeline.
In C, if you "inherit" a class, you can do so thus:
Z {
X z_x;
}
At first glance, that looks like a "has a" but it's really an "is a" in this context. That is essentially what C++ does [invisibly] and in C you just do z.z_x.fncX4 instead of z.fncX4. And, you can put a comment that says "// don't use fncX12" in Z. So, if you do that, how do you classify it?"x = y" can generate a copy constructor or a copy assignment operator. If either of these is overloaded in the class, they can generate a "deep copy" whether you want it or not. In C, "x = y" either copies the scalar value, pointer value, or does a struct element by element copy (e.g. can be done with memcpy). In C, if you wanted a "deep copy" (e.g. a member has a char *, and you do a strdup), you'd create a "deep_copy" function and you'd say "x = deep_copy(y)". That is explicit as to intent.
Another example: "x += y" might generate a huge amount of code because the creator of the X class decided that the "+" and/or "+=" operator should do things with a database. That's an abuse. The creator clearly abused things, but the [hapless] programmer trying to find this would have their work cut out for them. They're not going to be able to check every "+" statement for "is this overloaded in an insane/abusive way?". If the "+" were actually a member function called "plus" or better yet "addto", a reviewer would be much more clued in to look at the "addto" function than a simple "+".
Or, the "+" operator is defined such that if you were using an unsigned int it prevents wrap (e.g. 0xFFFFFFFF + 1 --> 0xFFFFFFFF instead of 0--common for some video calculations and saturation). Somebody who is not the original author would probably not realize this on the first pass through the code and might take much longer to realize that this is the bug they're looking for (e.g. the value needs to wrap to 0). If you want FF+1 --> FF instead of 0, create a sat_add function that does the job. You'd have to do that anyway in any OO lang that doesn't support operator overload (e.g. java)
And, don't get me started on ">>" and "" for streams. This is one of C++ most obvious "hacks". People realize how defective it is, but swallow it, because it's ubiquitous and idiomatic, but nobody should try to defend it.
As to polymorphic functions:
void foobar(int i)
void foobar(float x)
void foobar(int i,int j)
Is that incorrect?
What the trial found was that:
vo -
Deja Vu all over again...
Gee, an Apple product did this in the 90's, compressing memory segments assigned to processes not currently executing.
(see, for example, https://www.usenix.org/legacy/...)
The same product was Apple's first to use pre-emptive multitasking,
The product? Newton. -
Re:Android or is it Java?
According to the article:
"Further analysis showed that many of the SDKs were vulnerable due to weak code generated by SWIG, an interoperability tool that connects C/C++ with variety of languages, when fed with some bad configuration given by the developer." https://www.usenix.org/confere...
So it doesn't sound like Java. -
Re:How is this different from an optimizer?
-
Re:Slimmer devices
The SoC in modern devices doesn't take anywhere near as much power as the screen or the cellular/wireless connection, so improvements to the fabrication process aren't going to add a significant amount of battery life. Here's a link to an analysis of the power consumption of the Openmoko phone (PDF warning) that shows that for most use cases, the SoC is only a minor part of the total power draw of the system.
Thinness is mostly a by-product of being able to cram more circuits in a smaller space which cuts down on the size of the logic board more so than battery life improvements have allowed for smaller batteries. -
Re:Bad RNG will make your crypto predictable
Also, when you are ready to take a leap from little knowledge, to a little bit more knowledge, read this paper: https://www.usenix.org/system/...
-
Re:Old paper is old
-
Re:Achilles heel of the cloud apps....
SAML ? Don't make me laugh:
"In this paper we describe an in-depth analysis of 14 major SAML frameworks and show that 11 of them
... have critical XML Signature wrapping (XSW) vulnerabilities"" In order to protect integrity and authenticity of the exchanged SAML assertions, the XML Signature standard is applied. However, the signature verification algorithm is much more complex than in traditional signature formats like PKCS#7. The integrity protection can thus be successfully circumvented by application of different XML Signature specific attacks, under a weak adversarial model."
-
For those interested...
Go was developed in large part by Rob Pike who has a long history of concucrrency programming going back to Plan 9 from Bell Labs and earlier.
Some of his more interesting papers about concurrency are:
http://swtch.com/~rsc/thread/n... (The Newsqueak Programming Language)
http://swtch.com/~rsc/thread/n... (Newsqueak Implementation)
https://www.usenix.org/legacy/... (A Concurrent Window System)You can even see some hints of what was to come in his paper outlining the design of the Blit terminal for Unix:
http://doc.cat-v.org/bell_labs... -
Re:Marked Paper Ballots FTW
The best electronic system you can think of is a Rube Goldberg compilation of spread sheets and Access databases.
Actually, I was thinking of the Diebold AccuVote TsX and its GEMS and BallotStation software, although that was a pretty good description of how it works under the hood. You've probably voted on it, and it has been used to elect congressmen, senators and presidents, so maybe you should know how it works.
You are either an idiot or a liar. Either way, you've proven you are incapable of discussion, intelligent or otherwise.
Ah, the classic "Well, you're a poo-poo head and I don't wanna debate wif yoo no more" defense. I bow to your superior intellect and will trouble you no more.
-
Re:Who cares
Modern IOS versions randomize the MAC used for passive wifi scans. I'd imagine android is also doing the same.
Its been said that this is how they have changed IOS 8, however
I've only noticed that they have decreased the number of beacons it sends greatly;
the same MAC is used for the probes; and given the ability to profile devices passivly [pdf],
the MAC may not be the only thing to worry about.If you have a wireless card that can go into monitor (radio promisc) mode,
you can see all of the probes constantly travelling around us:
tshark -i mon0 -R 'wlan.fc.type_subtype eq 4' -T fields -e wlan.sa -e wlan_mgt.ssid -e radiotap.dbm_antsignal -e frame.time -E separator=, -E quote=dThing is the penetration of these monitoring techniques is difficult to
ascertain, I've been looking for them when I visit big retailers, but
according to people like Glenn Wilkinson and Brendan O'Connar,
these may be fairly easy to setup and in wide use surreptitiously.
(Authors of Snoopy and CreepyDOL) -
Re:Submitter doesn't understand Wikipedia notabili
A couple new answers to that question have popped up in the intervening time.
-
Re:Submitter doesn't understand Wikipedia notabili
A couple new answers to that question have popped up in the intervening time.
-
Re:Would it hurt ...
MongoDB uses mmap but the similarity ends there. It uses a journal, not COW. It suffers from a number of durability and consistency vulnerabilities. LMDB has no such weaknesses.
http://www.slideshare.net/mong...
This research group at University of Wisconsin cites 1 vulnerability for LMDB, but they were mistaken:
-
23rd USENIX Security Symposium - 8/2014 - Full Pro
23rd USENIX Security Symposium - 8/2014 - Full Proceedings
#####
- Main Page:
https://www.usenix.org/confere...- PDF Download:
https://www.usenix.org/sites/d...- More format options than PDF including iPad/eReaders/Mobile Devices:
https://www.usenix.org/confere...-- View on-line, each page as separate image files rather than PDF:
http://view.samurajdata.se/ -
23rd USENIX Security Symposium - 8/2014 - Full Pro
23rd USENIX Security Symposium - 8/2014 - Full Proceedings
#####
- Main Page:
https://www.usenix.org/confere...- PDF Download:
https://www.usenix.org/sites/d...- More format options than PDF including iPad/eReaders/Mobile Devices:
https://www.usenix.org/confere...-- View on-line, each page as separate image files rather than PDF:
http://view.samurajdata.se/ -
23rd USENIX Security Symposium - 8/2014 - Full Pro
23rd USENIX Security Symposium - 8/2014 - Full Proceedings
#####
- Main Page:
https://www.usenix.org/confere...- PDF Download:
https://www.usenix.org/sites/d...- More format options than PDF including iPad/eReaders/Mobile Devices:
https://www.usenix.org/confere...-- View on-line, each page as separate image files rather than PDF:
http://view.samurajdata.se/ -
Re:My opinion on the matter.
FreeBSD uses init.d
FreeBSD uses rcNG, acquired from NetBSD (basically shell scripts and a binary for resolving dependency order defined in magic comments), on top of a simple BSD-style init. There's some vague movement towards porting launchd, but I don't think anyone's holding their breath.
-
23rd USENIX Security Symposium - 8/2014 - Full Pro
- Main Page:
https://www.usenix.org/confere...- PDF Download:
https://www.usenix.org/sites/d...- More format options than PDF including iPad/eReaders/Mobile Devices:
https://www.usenix.org/confere...-- View on-line, each page as separate image files rather than PDF:
http://view.samurajdata.se/ -
23rd USENIX Security Symposium - 8/2014 - Full Pro
- Main Page:
https://www.usenix.org/confere...- PDF Download:
https://www.usenix.org/sites/d...- More format options than PDF including iPad/eReaders/Mobile Devices:
https://www.usenix.org/confere...-- View on-line, each page as separate image files rather than PDF:
http://view.samurajdata.se/ -
23rd USENIX Security Symposium - 8/2014 - Full Pro
- Main Page:
https://www.usenix.org/confere...- PDF Download:
https://www.usenix.org/sites/d...- More format options than PDF including iPad/eReaders/Mobile Devices:
https://www.usenix.org/confere...-- View on-line, each page as separate image files rather than PDF:
http://view.samurajdata.se/ -
LISA Conference
I go to this conference at least once every 2 years https://www.usenix.org/confere...
-
try these lists ...USENIX, OSCON, VMworld
This should get you started. USENIX https://www.usenix.org/confere... VMWorld http://www.vmworld.com/index.j... OSCON (must wait until 2015) http://www.oscon.com/oscon2014...
-
SysAdmin Code of Ethics!
Read the:
USENIX System Administrators' Code of Ethics
LOPSA System Administrators' Code of EthicsYou're an IT PROFESSIONALl now. Act like it. Ignore the politics.
With "root"/"Administrator" account access to IT systems, you're basically God and have access to everything in IT. TRUST IS EVERYTHING between IT administrators and your users.
There was a time when bankers and accountants were highly respected because they had a fiduciary duty to their clients/customer. Following the recent economic crash of the Great Recession and Enron-type scandals, the reputations of companies like Goldman Sachs and Arthur Anderson were significantly tarnished and people's perception of them have noticeably changed. Sure, there's always been other scandals/incidents before but most people only remember the most recent big ones.
Physicians have their Hippocratic Oath, Professional Engineers have their Obligation of the Engineer, and lawyers have their professional code. Yes, every day, there's some new news story of a medical doctor, engineer, or lawyer violating all or some part of these oaths. The intention is that we all like to think/hope that as professionals, we can strive to maintain these goals and call out the ones who have gone astray.
All workplaces have some sort of internal office politics. This is what happens in any size or type of company or organization of humans due to company/organizational policies and just the nature of individuals (which tends towards being selfish or fiefdom-protecting). Being a "non-profit" is ultimately more of a tax status issue and does not automatically mean the entire non-profit organization or that all of its workers are 100% perfect, selfless, always altruistic individuals who all agree on everything.
More criminal minds might call such altruistic people "suckers" depending on the situation. Or what sometimes happens is that the altruistic individuals in charge made false assumptions about the costs or labor involved for operations and refuse to believe that we can't just all work for free or get stuff/materials for free just for the "good of the children blah blah blah". How many rich donors can you really get?
The goal is to find a job that has office politics which you can reasonably tolerate. Since you said you're new, there may be other background history in your organization that you're not aware of that you're just stumbling across now.
And yes, there's always 1 (or more) "crazy people" in any company/organization. Be cautious in dealing with them. Do your job (e.g. fix their computer if broken) but don't get looped into whatever personal agenda they're advancing.
Really doing something about any of the office politics sometimes might mean getting your manager involved (or becoming a manager). A good manager can serve as your "shield" (or "scapegoat" depending on your viewpoint) so you can defer/blame certain things to them ("I'd like to help you but my boss lady said I can't. Talk to her about it."). This is not a path to be chosen lightly.
All that being said...always keep your resume/CV up-to-date and your co-worker and business relationships cordial. Separate your work stuff from your personal stuff. Getting too entangled in this can turn into utter poison for yourself and your future career.
Sometimes, you've just go to bail. Really. If you can describe your workplace with the one word of "miserable" and you've made reasonable efforts to deal with it in a reasonable time period (maybe 3-6 months?), it's really time to go.
Even though it's kind of really targeted towards managers, Patrick Lencioni's book
-
LOPSA/LISA Code of Ethics
Read the System Administrators' Code of Ethics and take it to heart. Even if your job title doesn't include the words "system" or "administrator."
It's actually pretty easy to ignore the content of an email if you're focused on the email delivery process (mail server logs, the headers of forged/spam mails, things like that). Similarly, if you're doing FTP hosting or file drops for customers, you rarely need to dig into the content of the files themselves to troubleshoot upload/download problems. There are rarely reasons to dig into the content of whatever you're working on. It does come up, if (for instance) some piece of email has wacky malformed content that keep crashing the mail client, but IME those situations are uncommon.
I used to work at a mom-and-pop ISP, in a small town. Our customers included the local police and fire departments, City Hall, and most of the larger law offices and accountants' offices. Since we provided email and Web hosting (among other services), I certainly could have made some locals' lives very interesting. Hell, I had access to the email of everyone in my company, including that of the owners to whom I reported. I'll admit to having been tempted once or twice, but I'm proud to say I never abused my privilege.
-
Arrest the parents!!!
I was under the impression TOR was explicitly designed to allow others to break the law
Tor was explicitly designed created through a grant by the US. Naval research Laboratory as " a circuit-based low-latency anonymous communication service".
Sometimes people with power are so stupid, it boggles the mind. This discussion about holding Tor node operators responsible as accomplices for things done on the Tor network is so offensive and ridiculous as to almost not warrant a response.
-
Re:Wha?
Read the first half "Introduction and Roadmap" in a paper on the topic from last summer here.
-
Re:Why can't Microsoft do this?
The more curious question is why Microsoft can't sell this. They were perfectly capable of putting together
.NET Micro, which runs on fairly tiny stuff, and they've been poking at ambient embedded devices at least since SPOT and various DirectBand receiver devices. More recently, there was "Windows Sideshow", which more or less died without a whisper; but was a serious stab at making semi-autonomous devices, intermediate between ye olde serial LCD and the PDA/Phone/MP3 player that is just here to sync and then leave, work with full PCs in interesting ways.
On the research side (and even further from commercial success, since as far as I know they never actually deployed it), they put together a proof-of-concept of using a small embedded processor to allow a PC to remain sleeping most of the time, while continuing to behave exactly as normal from the perspective of other devices on the network, by handing off tasks to the embedded device, which could then wake the host PC as needed to pass off results or respond to spikes in demand beyond its capabilities. (They never went beyond a demo, to my knowledge; but this seems like the sort of thing that could get very interesting if you took advantage of the CLR to allow a .NET application to move bits of itself between the host and the slave device, regardless of underlying architecture...)
Back when they were still flogging warmed-over piles of DOS with a layer of GUI and instability, the big mystery was why Microsoft was so incompetent. What mystifies me now is how they manage to turn massive supplies of money and talent into such comparatively limited success outside of their traditional markets. -
+1 Re:Smalltalk live images
Mod parent up. Not sure if this New Yorker cartoon from the most recent issue will stay around long, but I saw it this morning and it sums up how I feel about much of computer software development the last thirty years since Smalltalk:
http://www.newyorker.com/image...A character says "The new house is almost ready!" and it looks exactly the same as the rundown house in almost exactly the same location.
Software could be better, like the character could in theory have built a better house. But in practice, watching this play out of 30 years myself, much of what we get is just re-re-re-inventing the wheel. And there is a terrible waste in having to re-learning it slightly differently with slightly different bugs and limits, and little true progress. Often there is regress, since Smalltalk's keyword syntax is still more readable and expandable than C-like syntax.
Where would we be now if a truly free Smalltalk had had all the billions poured into it that Java had due to IBM and Sun's marketing clout and all the effort that has gone into JavaScript dues to Netscape/Mozilla/Google/etc.? Including the best of any LightTable ideas (a view with source when you hover over a name in code is indeed cool) and any other GUI improvements? As well as better libraries and better cross-platform support and better browser integration and so on?
Still, maybe JavaScript is the best we could hope for at this point, and better than we deserve, as someone else said and I echo in this submission from yesterday about James Mickens' last "USENIX "login" column explaining all that is wrong with the Web pages technically:
http://slashdot.org/submission...
Citing: https://www.usenix.org/system/...But we got that mess for social reasons (competition, centralization, monetarization), not technical one, like I mention here:
http://slashdot.org/comments.p...Social stuff like ParcPlace not being willing to license ObjectWorks/VisualWorks cheaply to Sun when they wanted to do a set top project (which ultimately lead to sun making Java).
Could Smalltalk be improved? Yes. Even the syntax could, like by using more C-like strings and comments while keeping the keywords. Could it benefit from type annotations for optimization? Probably yes too. And could it benefit from being built from textual sources instead of an image (like GNU smalltalk). Again yes. But investments in that direction would have produced so much more benefits than something like Java or JavaScript.
That said, after all the pain and suffering and waste, Java and JavaScript/HTML5/CSS3 have finally become half-way decent platforms. I'm moving more in a JavaScript direction myself for mostly social and practical reasons, despite knowing how great Smalltalk was and seeing how much it could have become. I talk about that on Slashdot here:
http://slashdot.org/comments.p...
http://developers.slashdot.org...Smalltalk might still get there building on Java and JavaScript as with these projects:
http://amber-lang.net/
http://www.redline.st/Mickens' comments are mostly true, but end up being tradeoffs for ubiquity and easy installs in the case of JavaScript -- even Alan Kay and Dan Ingalls agreed on that with their efforts toward the Lively Kernel driven by the fact they could not get many people to install Squeak or Squeak-based apps).
http://www.lively-k -
Re:Requires Javascript.
> JavaScript is not evil when used properly.
Javascript is not evil at all!
> True, it is one of the worst ever designed languages
I disagree on that too.
-
Re:no capacitors
I don't expect total power loss protection. I do expect reasonable behaviour, like data already synced to the drive is there even after a power loss. SSD drives without capacitors fail spectacularly, they are much worse than HDD drives. Just google for "SSD failure modes abstract", for example: https://www.usenix.org/system/...
-
re: drive throughput
IIRC Backblaze's workload is write once read maybe once (I mean, they are a backup company). So it's quite likely that they are massively under the specs for throughput.
The truly interesting thing about this study is that they name names; previous work in the area (lke Bianca Schroeder's FAST 07 paper, http://www.cs.cmu.edu/~bianca/... or Google's FAST 07 paper, http://research.google.com/arc..., or NetApp's FAST 08 paper http://www.usenix.org/event/fa...) doesn't give away vendor names. The Backblaze results broadly agree with the previous results.
-
Re:What security does Bluetooth have?
Hi, I'm a Bluetooth Security researcher. My primary focus is on BLE for which I built a highly robust sniffer on the Ubertooth platform. I have experience in other aspects of Bluetooth.
TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.
Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.
Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.
BLE has major weaknesses in its pairing protocol that I spoke about at BlackHat USA 2013 and other venues. For the most recent video see my presentation at USENIX WOOT 13.
In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.
Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.