Plus, this allows the possibility of open-sourcing additional software that was built on top of this stuff back in the day. In the late 80s and early 90s, I worked on library automation software, and the Unix version of it was built on top of the libraries that were part of CDE. That code can in theory now be dusted off and released.
You don't always need to track days/hours worked. For many salaried employees, you get paid an annual salary and your hours aren't really supposed to be tracked.
The vacation day policy lays on top of that. If you use more than you're supposed to, it's not that you're getting paid for more days than you're supposed to, it's that you're getting paid the right amount but you're also violating company rules/policies.
(This is how it is for my own job.)
The vacation tracking system doesn't really need to sync up with anything else in situations like this. In my own case, the vacation tracking system needs to emit three pieces of data once a year: 1) was the policy complied with? 2) how many "ordinary rollover days" get fed into the formulas for the next year? 3) how many "sick day bank days" get fed into the formulas for the next year?
Of those, only #1 is ordinarily used outside of the vacation/PTO tracking workflows, so from the outside, the only data syncing is normally "did this employee comply with policy or not?".
My own PTO days are tracked via a spreadsheet. My employer uses Excel, but I keep my own "shadow copy", usually in Google Docs spreadsheets (it has varied year-to-year).
There are plenty of open source spreadsheets. The first one that I really liked using, many years ago, was "sc", a curses/terminal-based spreadsheet that built upon the vi keyboard commands. It's still around somewhere. My housemates and I used it collectively (via shared directories with ACLs on NFS mounts) to track shared expenses. There are many modern GUI options, of course.
Whether something more complicated than a spreadsheet is worth thinking about depends on details you haven't given us yet. What are your actual requirements? What's your PTO/vacation policy?
So, the author has a theory, that sales on top of a fundamentally open platform have an inherent problem because the platform itself is "built for piracy".
Android may be open, but Ubuntu Linux is even more open, no? I mean, on Android you've got a bunch of closed-source components, particularly around payment processing and app purchase, right?
It's going to be very interesting to see how Steam fares on Ubuntu. How many developers are going to sell their games for Linux this way? Once things have been out for a while, how will the piracy rates on Linux, Windows, and MacOS (for the same application via the same delivery mechanism) compare to each other?
Also: I wonder what the author thinks of GoG. They seem to be making enough to stay in business, even though one of their selling points is "no DRM, at all, period, ever".
(Frankly, I think the bigger reason Android has more of a piracy problem than iOS has more to do with the number of budget phones on prepaid plans that run Android. Leaving all other issues aside, Android's considerably more likely to be in the hands of a cheapass than iOS is.)
You might be replacing your DE as often as you change your underwear, but not all of us are doing so. My favorite DE is older than OSX.
So's mine, even though it basically is OSX.
Ever since about 1989 or so, my favorite GUI environment has been NeXTstep. My employer got prerelease access (since we're Carnegie Mellon, where the Mach kernel came from), and it's essentially been my favorite desktop environment since version 0.8 or so, back when I taught myself Objective-C programming on it.
I pretty much hated "classic" MacOS and didn't like most Apple products except HyperCard and the Newton, right up until Apple required NeXT. So much of what was great back then is still here. I wish they'd managed to keep the old application remote display mechanism (NXHOST =~ DISPLAY), but the unreasonably-licensed Adobe Display PostScript pretty much put an end to that... alas.
If Apple screws it up too much (and signs are that they might, though I don't think they have yet), well, I'll probably end up switching to Ubuntu with GNUstep.
If using the GUI tool saves you time (or other costs) over the completely lifespan of the content produced, go for it. (An example might be a party announcement that's viewed by three dozen people for a week and then never needs to be seen again.)
If using the GUI tool would save you up-front time while designing, but would increase the cost of maintaining or updating the site, use it for prototyping but not for the deployed version. (Examples are easy to imagine, especially if you collaborate on the design with less technical people.)
If using the GUI tool wouldn't save you any time at all, then mess around with it in your spare time so that you know what to expect when you encounter others who use it, content produced with it, et cetera, but don't use it on real projects (or, not unless you have spare time and don't "bill the customer" for the extra time you're burning). (Heck, you might spot a way to build a more useful GUI tool that makes you filthy rich.)
I'd be very surprised to see Unity enthusiastically adopted by the broader Linux community (packaging it is one thing; getting more than a handful of users to install it is quite another).
If you mean current Linux users, that's one issue. But another issue is: to what extent will Unity entice non-Linux users to become Linux users?
(I'm talking about on the desktop.)
I personally know very few people who use Ubuntu on the desktop. Of those people, none used it at all before 12.04, and none have switched away from Unity.
(I happen to be in this set myself. I've been a Linux user on servers since well before the switch from a.out to ELF. I used it on the desktop in the mid to late 90s, but not since -- every time I gave it a try, I quickly went back to other desktop operating systems. But now I'm using Ubuntu, and so are non-techie relatives, and a couple of other people around me.)
Interesting. None of the Ubuntu users I know are using anything other than Unity.
But then, none of them were Linux desktop users until Ubuntu 12.04 either.
(Well, I was, back in the 1990s. But not for like 12 years or so. The main thing I've found annoying about Unity is how hard it is to turn off virtual desktops/workspaces. Was tempted to switch back to TWM until I figured it out.)
Why would Facebook spend money policing it's patrons and voluntarily reporting misdeeds? They are a "for profit" company, not a social service.
So that when legislators start asking questions about their violations of user privacy, they can point at examples like this to show how it's really "for the children" and in support of our fine laws and all that drek, maybe?
None of what you wrote has anything to do with what I wrote. None of it has anything to do with the sharing feature. I'm trying to see how what you wrote wasn't a non-sequiter.
Let me spell out what I can see. You can tell me if I'm missing anything.
Both iCloud and iWork involve both app-based and web-based functionality. The only place you can see all of the app-based functionality is via the iOS apps, so let's just completely ignore the MacOS apps for now. They have nothing to do with what I'm talking about.
With the iWork service, there is a built-in sharing function. I can upload a Pages document, and create a URL that I can pass to other people who do not have my login credentials. Those people can then download the document in Pages, PDF, or Word format.
With the iCloud service, there is no sharing mechanism at all for documents. I can sync or upload a Pages document to iCloud, but there is no way to get it back out of iCloud without my login credentials. So the sharing function is completely, utterly absent.
(And, it ain't in beta.icloud.com either. I did research that.)
Unless I'm missing something. Am I missing something?
Documents sharing services were incorporated into iCloud thus making iWorks.com redundant.
I cannot find the sharing services. Got a pointer?
If I sync a Pages document up to iCloud, I see how I can download it in Word, Pages, or PDF formats. But I cannot see a mechanism that lets me allow you to do so.
Except that they are retiring "real" cloud storage like iDisk and only allowing documents...
But iWork was already "only allowing documents".
What we're giving up here isn't general-purpose-ness, but sharing-and-conversion features. Today, you can publish an iWork document via this site, send around the URL, and have people download it in iWork, Office, or PDF formats. I don't see a replacement for that yet.
(But I didn't see a replacement for MobileMe Galleries either, and there are at least two half-assed replacements for that in iCloud. So, we'll see, maybe it'll come.)
(If you have two different half-assed ways to do something, does that result in a complete ass? Hm.)
...I'll be amused as hell, because that's about the screen size of the Newton MP2000 that was often rejected as way too large (the PalmPilot's tiny size being something of a reaction to this).
Actually, a bunch of the APIs aren't even proprietary. A bunch of it is just an evolution of an openly-developed standard, with two companies behind it, that was deployed on multiple operating systems and multiple hardware platforms, and that has an open source implementation today.
Actually, yes, thank you very much. The places I'd been watching all stopped updating around the time Leopard came out. I have absolutely no idea how I missed that.
There is nothing you can do with Lin-sux that I cannot do on OS X...
That's great! Can you give me pointers on how to get a new scheduler into the OS X kernel? I've got some experiments with realtime processing that I want to run.
I used to know how to do it, but since they stopped updating the Darwin kernel in order to kill Hackintoshes, I no longer know how.
Depending on how bad his arthritis is, you could take over the wiring and he could start writing the code.
You beat me to it! Let me elaborate on this by suggesting that each of you should spend time teaching the other the missing specialty. Don't just take over the wiring, have him teach you how to do it right, while you teach him to code.
They're saying "providing a consistent GPU experience across multiple platforms for all of our customers continues to be one of our key goals".
So, my interpretation of that is:
"If we released the drivers as open source, then people might figure out how to optimize and tune the Linux drivers. This could result in a better GPU experience on Linux than under Windows. That would embarrass us. To ensure a consistent experience across platforms, we therefore must prevent others from tinkering with the drivers, which mandates closed source."
It's not just assuming you run other programs than emacs, but further assuming you do not run those programs within emacs. Because, if you do, the normal emacs mechanisms work just fine (as they have since I developed the habit in the late 1980s).
If the day comes that I want to use a mouse for copy/paste operations in Emacs, I may give it a try. Today, I tend not to touch the mouse when I'm in Emacs.
Slashdot Mirror
Historical interest is worthwhile.
Plus, this allows the possibility of open-sourcing additional software that was built on top of this stuff back in the day. In the late 80s and early 90s, I worked on library automation software, and the Unix version of it was built on top of the libraries that were part of CDE. That code can in theory now be dusted off and released.
You don't always need to track days/hours worked. For many salaried employees, you get paid an annual salary and your hours aren't really supposed to be tracked.
The vacation day policy lays on top of that. If you use more than you're supposed to, it's not that you're getting paid for more days than you're supposed to, it's that you're getting paid the right amount but you're also violating company rules/policies.
(This is how it is for my own job.)
The vacation tracking system doesn't really need to sync up with anything else in situations like this. In my own case, the vacation tracking system needs to emit three pieces of data once a year:
1) was the policy complied with?
2) how many "ordinary rollover days" get fed into the formulas for the next year?
3) how many "sick day bank days" get fed into the formulas for the next year?
Of those, only #1 is ordinarily used outside of the vacation/PTO tracking workflows, so from the outside, the only data syncing is normally "did this employee comply with policy or not?".
My own PTO days are tracked via a spreadsheet. My employer uses Excel, but I keep my own "shadow copy", usually in Google Docs spreadsheets (it has varied year-to-year).
There are plenty of open source spreadsheets. The first one that I really liked using, many years ago, was "sc", a curses/terminal-based spreadsheet that built upon the vi keyboard commands. It's still around somewhere. My housemates and I used it collectively (via shared directories with ACLs on NFS mounts) to track shared expenses. There are many modern GUI options, of course.
Whether something more complicated than a spreadsheet is worth thinking about depends on details you haven't given us yet. What are your actual requirements? What's your PTO/vacation policy?
So, the author has a theory, that sales on top of a fundamentally open platform have an inherent problem because the platform itself is "built for piracy".
Android may be open, but Ubuntu Linux is even more open, no? I mean, on Android you've got a bunch of closed-source components, particularly around payment processing and app purchase, right?
It's going to be very interesting to see how Steam fares on Ubuntu. How many developers are going to sell their games for Linux this way? Once things have been out for a while, how will the piracy rates on Linux, Windows, and MacOS (for the same application via the same delivery mechanism) compare to each other?
Also: I wonder what the author thinks of GoG. They seem to be making enough to stay in business, even though one of their selling points is "no DRM, at all, period, ever".
(Frankly, I think the bigger reason Android has more of a piracy problem than iOS has more to do with the number of budget phones on prepaid plans that run Android. Leaving all other issues aside, Android's considerably more likely to be in the hands of a cheapass than iOS is.)
So's mine, even though it basically is OSX.
Ever since about 1989 or so, my favorite GUI environment has been NeXTstep. My employer got prerelease access (since we're Carnegie Mellon, where the Mach kernel came from), and it's essentially been my favorite desktop environment since version 0.8 or so, back when I taught myself Objective-C programming on it.
I pretty much hated "classic" MacOS and didn't like most Apple products except HyperCard and the Newton, right up until Apple required NeXT. So much of what was great back then is still here. I wish they'd managed to keep the old application remote display mechanism (NXHOST =~ DISPLAY), but the unreasonably-licensed Adobe Display PostScript pretty much put an end to that... alas.
If Apple screws it up too much (and signs are that they might, though I don't think they have yet), well, I'll probably end up switching to Ubuntu with GNUstep.
If using the GUI tool saves you time (or other costs) over the completely lifespan of the content produced, go for it. (An example might be a party announcement that's viewed by three dozen people for a week and then never needs to be seen again.)
If using the GUI tool would save you up-front time while designing, but would increase the cost of maintaining or updating the site, use it for prototyping but not for the deployed version. (Examples are easy to imagine, especially if you collaborate on the design with less technical people.)
If using the GUI tool wouldn't save you any time at all, then mess around with it in your spare time so that you know what to expect when you encounter others who use it, content produced with it, et cetera, but don't use it on real projects (or, not unless you have spare time and don't "bill the customer" for the extra time you're burning). (Heck, you might spot a way to build a more useful GUI tool that makes you filthy rich.)
I weep at the lost opportunity for rickrolling.
If you mean current Linux users, that's one issue. But another issue is: to what extent will Unity entice non-Linux users to become Linux users?
(I'm talking about on the desktop.)
I personally know very few people who use Ubuntu on the desktop. Of those people, none used it at all before 12.04, and none have switched away from Unity.
(I happen to be in this set myself. I've been a Linux user on servers since well before the switch from a.out to ELF. I used it on the desktop in the mid to late 90s, but not since -- every time I gave it a try, I quickly went back to other desktop operating systems. But now I'm using Ubuntu, and so are non-techie relatives, and a couple of other people around me.)
Interesting. None of the Ubuntu users I know are using anything other than Unity.
But then, none of them were Linux desktop users until Ubuntu 12.04 either.
(Well, I was, back in the 1990s. But not for like 12 years or so. The main thing I've found annoying about Unity is how hard it is to turn off virtual desktops/workspaces. Was tempted to switch back to TWM until I figured it out.)
It all makes sense now! They're prepping for a massive cyber-war in the mid 21st century!
So that when legislators start asking questions about their violations of user privacy, they can point at examples like this to show how it's really "for the children" and in support of our fine laws and all that drek, maybe?
None of what you wrote has anything to do with what I wrote. None of it has anything to do with the sharing feature. I'm trying to see how what you wrote wasn't a non-sequiter.
Let me spell out what I can see. You can tell me if I'm missing anything.
Both iCloud and iWork involve both app-based and web-based functionality. The only place you can see all of the app-based functionality is via the iOS apps, so let's just completely ignore the MacOS apps for now. They have nothing to do with what I'm talking about.
With the iWork service, there is a built-in sharing function. I can upload a Pages document, and create a URL that I can pass to other people who do not have my login credentials. Those people can then download the document in Pages, PDF, or Word format.
With the iCloud service, there is no sharing mechanism at all for documents. I can sync or upload a Pages document to iCloud, but there is no way to get it back out of iCloud without my login credentials. So the sharing function is completely, utterly absent.
(And, it ain't in beta.icloud.com either. I did research that.)
Unless I'm missing something. Am I missing something?
I cannot find the sharing services. Got a pointer?
If I sync a Pages document up to iCloud, I see how I can download it in Word, Pages, or PDF formats. But I cannot see a mechanism that lets me allow you to do so.
But iWork was already "only allowing documents".
What we're giving up here isn't general-purpose-ness, but sharing-and-conversion features. Today, you can publish an iWork document via this site, send around the URL, and have people download it in iWork, Office, or PDF formats. I don't see a replacement for that yet.
(But I didn't see a replacement for MobileMe Galleries either, and there are at least two half-assed replacements for that in iCloud. So, we'll see, maybe it'll come.)
(If you have two different half-assed ways to do something, does that result in a complete ass? Hm.)
...I'll be amused as hell, because that's about the screen size of the Newton MP2000 that was often rejected as way too large (the PalmPilot's tiny size being something of a reaction to this).
"C combines the power and performance of assembly language with the portability and ease-of-use of assembly language."
Yeah, when I started using it (back before PHP 3.0), it was actually called "PHP/FI", which stood for "personal home page / forms interface".
Actually, a bunch of the APIs aren't even proprietary. A bunch of it is just an evolution of an openly-developed standard, with two companies behind it, that was deployed on multiple operating systems and multiple hardware platforms, and that has an open source implementation today.
http://en.wikipedia.org/wiki/OpenStep
http://www.gnustep.org/
(Not all, sure. But a bunch.)
Actually, yes, thank you very much. The places I'd been watching all stopped updating around the time Leopard came out. I have absolutely no idea how I missed that.
Thanks again!
That's great! Can you give me pointers on how to get a new scheduler into the OS X kernel? I've got some experiments with realtime processing that I want to run.
I used to know how to do it, but since they stopped updating the Darwin kernel in order to kill Hackintoshes, I no longer know how.
So, um, how is that inconsistent with "on the way"? The standard may be written, but the implementation is still "on the way", no?
You beat me to it! Let me elaborate on this by suggesting that each of you should spend time teaching the other the missing specialty. Don't just take over the wiring, have him teach you how to do it right, while you teach him to code.
They're saying "providing a consistent GPU experience across multiple platforms for all of our customers continues to be one of our key goals".
So, my interpretation of that is:
"If we released the drivers as open source, then people might figure out how to optimize and tune the Linux drivers. This could result in a better GPU experience on Linux than under Windows. That would embarrass us. To ensure a consistent experience across platforms, we therefore must prevent others from tinkering with the drivers, which mandates closed source."
Does anyone else read it that way?
It's not just assuming you run other programs than emacs, but further assuming you do not run those programs within emacs. Because, if you do, the normal emacs mechanisms work just fine (as they have since I developed the habit in the late 1980s).
If the day comes that I want to use a mouse for copy/paste operations in Emacs, I may give it a try. Today, I tend not to touch the mouse when I'm in Emacs.