161–170 of 171 posts
> There was a brilliant programmer at Digitek who had completely novel and now unknown ideas for software development; he never published anything, but you could read and analyze his source code. Does anyone know about whom Knuth was referring? Did this have anything to do with the work on the PL/I compiler?
Earlier quoted context omitted.
we need to run programs with less authority than the user running them, and we still lack a good conceptual model for doing that Isn't this now the standard reality for most desktop and mobile OSs? "Allow write to SD card" is far, far too powerful a privilege to grant. Granting a permission based upon user approval is never secure anyway since if they want to see the porn / flashing lights they are going to click the…
> Isn't this now the standard reality for most desktop and mobile OSs? Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities. Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to…
Isn't this precisely how iOS works?
Earlier quoted context omitted.
The problem with this blanket rejection of "pop culture" as something lesser is that its almost always deployed by "young fogey" conservatives, harkening back to so golden imperial age. And of course these sort of people don't actually have any in depth historical knowledge.
I don’t read that quote as a blanket rejection of pop culture. Not at all.
Earlier quoted context omitted.
The disdain for history as an expression of you not knowing how to code wordpress is strange considering that, as you allude to, you don't know the latter. You may want to think whether learning wordpress is the same with learning history of html at decade level. Since you're publicly exposing your thoughts, let me tell you that what you are doing is expressing your ignorance and being proud of it. You may want to dr…
I've not shown any disdain for history or an inability to code wordpress... in fact, I've said the opposite: I like history and simply don't need it to code. I don't need to know history to code html, php, javascript, etc. I've a very successful programmer without using the "history' of programming in any shape or form. "expressing your ignorance" or... I'm simply expressing that I'm a successful programmer who's nev…
What I want to say is that there are entire domains of competence that are irrelevant to a large degree to doing the day's job. Knowing history of computing will not necessary help in making a better program in a way that can be noticed. But history of computing is closely related to computing. Unlike for example history of knitting. Although neither will make you a better programmer now, the first has much better chance at that than the second (although we don't exactly know that). Thus, when someone downplays the importance of history of programming to improving a programmer's mastery, I see it as touting ignorance at not seeing the connections between the two: self sufficiency, arrogance of ego being trapped by the light of today's fads, pop culture that doesn't care about the past or the future.
Or maybe I'm projecting...
Earlier quoted context omitted.
> Isn't this now the standard reality for most desktop and mobile OSs? Not really, no. Because there isn't a comprehensive intent layer in the UI that is fully trusted and in which the user can grant capabilities. Just a couple examples; if you download a PDF file with a mobile browser and want to open it in an app, the only option is to grant eternal (unless you manually revoke it) access to the local file system to…
> A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request an…
I'm not an expert on iOS. From reading their latest security guide and a bit of wikipedia I think the following is true:
* iOS uses the ZNU kernel, a Mach derivative with BSD POSIX environment with traditional POSIX processes, ipc, filesystems, and networking. * iOS implements runtime security by process/user-id separation and ACLs on system and inter-process APIs. The ReplayKit uses a similar idea by giving an app a handle on a single recording session, but it's implemented on top of the POSIX framework. For contacts it's clearly ACL based and either an app has access to all contacts or none whereas a capability system would allow a particular form of access to a single contact.
Capability systems are implemented by a kernel enforcing capabilities as the sole method of interacting with other objects in the system. There is no generic open(), connect(), read(), or listen() although there are similar methods on certain capabilities processes can hold.
For example, the user could provably give one contact to an app which was further allowed to share that contact with a third app under certain circumstances e.g. "schedule a call to Mom next Thursday" which would involve granting a scheduling app a capability to initiate a phone call but only to the number in the particular contact within a certain time window, by granting a re-grantable capability to the phone number (and maybe display name) subfield(s) of the Mom contact, which the scheduler would hand off to the phone dialer at the desired time. This is a mildly contrived example because of the complexity of generating the specific capabilities necessary to accomplish it, but it should give an example of what is possible to do securely with a capability system that would be difficult or impossible with traditional ACLs.
Earlier quoted context omitted.
Don’t all major OS have virtual desktops now? A single desktop is very restrictive, it’s much easier to have some spatial separation between contexts. It might not be the most visible feature for most users, but it is definitely an important one, which I would hate to see go away.
How do you use virtual Desktop in windows?
Earlier quoted context omitted.
I like history but how is history going to get me a functional game released or land a job interview? I don't need to know about DARPA to create a wordpress page or a C# Windows Service...
If you ever need to read something in one of Knuth's books, that's useful history for you. I know because I was looking how to efficiently generate power sets and eventually the only good answer was in TAoCP!!! So the answer is: history, the kind of history full of technical details that Knuth argues for, is extremely useful for our profession. It is the empty, pop history, made without algorithm descriptions and ful…
Earlier quoted context omitted.
History is not just about time — what happened when. An equally important part is the ordering and the reasons something happened. You can know how to write simple programs in all paradigms, but fail to understand what to use when. You might have memorized a long list of algorithms but not understand the trade-offs involved in choosing one. Of course history is not the only way to understand this, but it is definitel…
Well like I said... I enjoy history. but. I've never used history to solve business problems. They are related and good to know... but I don't need to know history to flip burgers, run a business or plan my next sprint. I'm not arguing history is unimportant or good to know or even possibly useful just to have ideas of what to do - or what not to do... I'm just arguing it's importance is over-emphasized.
Earlier quoted context omitted.
I've not shown any disdain for history or an inability to code wordpress... in fact, I've said the opposite: I like history and simply don't need it to code. I don't need to know history to code html, php, javascript, etc. I've a very successful programmer without using the "history' of programming in any shape or form. "expressing your ignorance" or... I'm simply expressing that I'm a successful programmer who's nev…
I was not entirely fair to you when trying to make my point. In fact I could see this exact argument of yours coming up and ignored it completely. What I want to say is that there are entire domains of competence that are irrelevant to a large degree to doing the day's job. Knowing history of computing will not necessary help in making a better program in a way that can be noticed. But history of computing is closely…
Maybe it's a combination of you "projecting" and me not being clear. And trying to discuss what could be deep conversations in a little more than a twitter tag of 140 chars.
I'm personally a .Net Developer and while I do stick with the latest versions (IE: .Net Core), I also have enough experience to know the past (IE: ADO vs Entity Frameworks). I was trained in school on a mainframe (IBM DB2 with RPG and SQL). I'm not trying to stick with the latest "hotness" as most of MY work is actually done via Windows Services, API interactions and moving files around - definitely not the latest fad. With that said, I am working on using good tools to get my job done faster/better - IE: CI/CD pipelines to automate builds, testing, deployment, etc. Tools that didn't exist 5 years ago could be the latest fad but I don't think that's what you are suggesting.
I'm more worried about learning different things (IE: Functional, procedural, async, parallel, etc) than I am worried about "history" of those. When I pick up a programming book, I'm less worried about the "Microsoft created version 1 in 2000 and version 2 in 2005 and..." and more concerned about do's, do not's, best practices, etc.
Maybe it's my personality and the way I "deemphasize" history... it's not that I think it's unimportant... I just think that it's more important to focus on other things. Learning some history along the way is good and fun but it's never been my focus and I've never used what I consider "history" in an interview or a job on a day to day. Maybe that's rubbing people the wrong way lol
Earlier quoted context omitted.
> A capability-aware UI would, at the "what do you want to do with this file?" system dialog grant a one time capability to read the particular file to the app the user picks. The capability persists as long as the app retains it. The app can't fork off a sub-process or send it to another app and clone the capability to the file; it would have to ask the user to do that. The mechanism for that trusted user request an…
> Isn't this precisely how iOS works? I'm not an expert on iOS. From reading their latest security guide and a bit of wikipedia I think the following is true: * iOS uses the ZNU kernel, a Mach derivative with BSD POSIX environment with traditional POSIX processes, ipc, filesystems, and networking. * iOS implements runtime security by process/user-id separation and ACLs on system and inter-process APIs. The ReplayKit…
Apps are heavily sandboxed on the app bundle level. Any code that's installed from the App Store in an app bundle has no way to access the filesystem outside of its sandbox. There is no "access the file system" permission like on Android or on desktop OSes.
Inter-app communication is extremely limited. There is no way for an app to launch a process in another app bundle. When you open a file from the system Files app, your app gets access to that file only.
There is a small handful of high-level APIs that allow inter-app communication, including a URL handler, and a "share this file" dialog box, where you give the OS a file URL and the OS lets the user pick another app and the OS grants access to only that file to the other app. There are also some very narrowly-defined APIs for audio plugin-type data stream integration (which is gated by App Store approval)
There is no OS-mediated way to share live objects (you can share objects, but the receiving app just gets a copy of the state of it at the time of sharing)
For the OS-managed databases (photos, contacts, music etc), the exposed APIs vary wildly in how they manage permission