moving people into STEM that would otherwise work in lower paid occupations.
While I can agree that the perspective is a bit protectionist, that would not pan out that way. Generally speaking, improving wages overall is either not going to happen, or happen because of inflation. While very rarely is something a zero sum game in economics, it also is the case that it doesn't at least somewhat behave like a zero sum situation. It's not necessarily a bad thing for society in general, but one should not pretend for a second that such moves would magically enable everyone to get six-figure standard of living.
Though I'm not usually dealing with Microsoft platforms, I have enough experience with it to consider classifying it as 'legacy' in any sort of universal way an odd proposition. It is after all *the* first-party supported development framework for Microsoft platforms, very much continuing to be supported and developed by a pretty important market force (like it or not).
Of course 'Legacy' is mostly in the eye of the beholder. About the only place 'Legacy' seems to have unambiguous meaning is within a single development organization replacing/phasing out projects they control. COBOL continues to see pretty significant deployments and is actively being enhanced, though most people in the industry would consider that 'Legacy'. Similar story for Fortran. A number of languages that don't get so much 'glory' these days continue to play important roles in particular segments and continue to be developed. There are those that would consider PHP 'legacy' and others just moving onto the platform. If you try to name a platform that by popular opinion is almost certainly totally 'Legacy' you'll probably discover not only some groups doing new development in the language, but some companies or projects actually continuing to enhance the language for others. Basically, if you can remember it, it by some definition is probably still alive.
To say it's 'export controlled' is an oversimplification of the restrictions around working with those nations.
But in simple terms, this is about *contributors*, not downloading. And if it weren't an issue, then Fedora people wouldn't be trying to game it for plausible deniability (which of course doesn't work when you say "Hey everyone, I want to be able to claim plausible deniability so could you just omit some information so I can do that?"
While I agree that a government is almost certainly not behind this and thoughts that it is are people thinking a bit too much of BitCoin. That said, hypothetically I could see why a government would choose an underhanded way to bring down something like this compared to overt regulation.
Consider that bitcoin is in no small part driven by people fanatically thinking fiat currency is the devil (for some very literally calling the dollar the mark of the beast) and that gold standard or something like that is 'the' answer to all that ails any economy. Explicitly banning it bears the risk of inducing the supporters to say 'see, told you so!' (even though there are very practical reasons to not let it get carried away, the reasons are sufficiently complicated and nuanced that it would be hard to simply explain).
Of course, knowing precisely why an unregulated currency of this nature is a bad idea would leave the opportunity for a government to cause it to collapse by exploiting those flaws. Most likely the flaws are just naturally being exploited because you don't have to give crooks a big reason to be crooks, but it is a strategy that might be more effective than blanket laws.
no utilities of your own written specifically for this purpose.
Why not? That is *precisely* what wolfram did here. He designed the 'language' and decided 'gee it would be nice to have a first class function for travelling salesman', and then when he goes to demo, he whips that out to say 'look at this obscure capability omitted from most languages'. This may be useful, but being excited around the linecount is not something compelling in this case, as it shows no particularly exciting grammer/syntax stuff, just that Wolfram deemed 'travelling salesman' a problem worthy of being a first class function in the namespace.
Pretty much anyone can submit an IETF RFC if they really want. The existence of a draft does not guarantee a ratified version will exist someday.
For another, it could be much worse. There is explicit wording at least here about seeking consent from the user and allowing opt-out even in the 'captive' case, as well as notifying the actual webserver of this intermediary, and that the intermediary must use a particular keyusage field meaning that some trusted CA has explicitly approved it (of course, the CA model is pretty horribly ill-suited for internet scale security, but better than nothing). Remember how Nokia confessed they silently and without consent had their mobile browser hijack and proxy https traffic without explicitly telling the user or server? While something like this being formalized wouldn't prevent such a trick, it would be very hard to defend a secretive approach in the face of this sort of standard being in the wild.
Keep in mind that in a large number of cases in mobile, the carriers are handing people the device including the browser they'll be using. A carrier could do what Nokia admits to in many cases without the user being the wiser and claim the secretive aspect is just a side effect today. If there was a standard clearly laying out that a carrier or mobile manufacturer should behave a certain way, that defense would go away.
I would always elect the 'opt out' myself, but I'd prefer anything seeking to proxy secure traffic be steered toward doing things on the up and up rather than pretending no one will do it and leaving the door open for ambiguous intentions.
Re:Why do you need an external camera to track hea
on
The Road To VR
·
· Score: 1
Even if it did need to have something like IR cameras to observe IR leds in the headset (or vice-versa, as the Wii did), I don't think it would be too bad.
Re:Why do you need an external camera to track hea
on
The Road To VR
·
· Score: 1
They have gyroscopic in there already. That's how they can do yaw and such. Still does nothing to help you with linear movement.
Perhaps not so far off...
on
The Road To VR
·
· Score: 5, Insightful
It's a big commitment to strap a giant, heavy device on your face with 3+ cables to your PC
Granted, but then again, a lot of particular prominent, even more special purpose successes require a pretty big commitment. Rock band did well and no one is going to claim it's trivial to whip out the guitars and drumset. Granted their success did not endure, but primarily because the experience lacked sufficient variety, it did show people were committed to go through some hoops. Similarly, *really* sitting down to enjoy a feature length movie requires some commitment (doing so without commitment is possible, but much less enjoyable.
there aren't many games in the Steam Store that support VR today
And there weren't many games that supported accelerated 3D graphics when 3dfx voodoo came out. Being too discouraged by that leads to a chicken and egg situation. It's probably also off putting that the set of available titles are at best adaptations of existing games or very basic things. The reason being that the quality games take longer and as such are still in progress (Star Citizen is one I'm really looking forward to). Crystal Cove demonstrates they will have capabilities the dev kits aren't even equipped to help publishers prepare for yet. Oculus is doing the only thing that might have a chance, building up a lot of excitement and coming in at an approachable price point to try to break the chicken and egg situation.
Having your eyes so close to the screens means the display is effectively very low resolution.
This is one area that has me pretty worried and waiting (that and the availability of good positional sensing). I'm really hoping they will be able to use at least a 2560x1440 OLED display (thanks to the mobile resolution pissing contest, Samsung looks ready to announce a shipping product with 2560x1440 at 5.2", 560 ppi seems very promising to construct a display out of, even if magnified).
VR is a surprisingly anti-social hobby, even by gamer standards
Very, very rarely is gaming remotely entertaining to mere observers. A lot of very popular things are *always* equally anti-social (texting, reading books, listening to music on headphones, pretty much doing *anything* on a smartphone or even tablet, laptop, or computer).
Notice how quickly we get into geez-this-is-a-lot-of-equipment territory.
The same can be true of racing or flying games, but that doesn't stop the vast majority of people making do with simpler controls. Just because you *can* take things very far at a very high price, doesn't mean you have to. The external tracking of the head is going to be baked into the headset cost (and not that expensive, as Kinect has shown) Headphones are straightforward as is positional audio in the headphone situation. Beyond eyewear and headphones, things get optional pretty fast. Wiimote-grade tracking for hands I certainly see as a big value add, but things start falling off real fast beyond that (the treadmill I'm skeptical would do anything to pull me that much more in as I think it would still feel very very off, but would wear me out greatly).
Re:Why do you need an external camera to track hea
on
The Road To VR
·
· Score: 2
They have accelerators in the headset. It doesn't do much good when at times the head can move at constant velocity. For sensing gravity and rotational movement, it works well, but translation movement is impossible to do reliably with accelerators lacking any sort of frame of reference.
Re:It is the journey to post-scarcity that is vita
on
Star Trek Economics
·
· Score: 1
I think the really difficult thing to overcome is when there truly is a labor surplus. Still a need for labor and particularly like you say, labor that not enough people 'just want' to do and particularly jobs almost anyone could do given a near trivial amount of training, but not enough demand to keep everyone meaningfully occupied.
Say hypothetically you are facing a situation that would mean massive unemployment, but realistically you could feed, clothe, shelter, and provide health care for everyone. But you still need people like delivery drivers. So either you provide all the fundamental needs for the unemployed and have a hard time finding people to do delivery work, or you resign society to screwing over the unemployed.
Of course, I think a key flaw that leads to this situation is the bad assumption that the choices are either 40 hours of work/week or 0 hours of work/week. A less ambitious goal might be to have more people working but for fewer hours. At least in the US, the stack is very heavily stacked against this evolution. The current healthcare situation is the worst of both worlds. When they first started talking health care reform, I imagined foolishly that we would be put on a path where one's employer did not have anything to do with coverage. Instead, it doubles down on that and as a result people are getting fewer hours, but without the health care. For such a goal to move forward, the 'magic' around 40 hrs/week has to go away.
Wealth stops being a concern for people once they're making over $70,000 a year.
While I agree there is more to motivation than money, that statement is just simply wrong. There was one dubious study that claimed that $75k maxed out 'happiness'. People still fret about acquiring compensation to put to some personal use well beyond $75k. Maybe somewhere up in the millions of dollars the dollar amount becomes more of a 'high score' than something to exchange for goods/services, but it's definitely not at $70k.
Good luck collecting on that clause when the student is in another country.
In all fairness, the same can apply to a loan. If you are in a country whose laws do not recognize your liability to your previous government, they likely don't recognize your liability for the loan. I think that the list of nations where that would work is pretty short and many of which are not exactly places you'd want to be.
While I am not sure how I feel about such a thought, he does present an interesting perspective. University in many cases presents a conflict of interest. An aspect of university is to prove to other people how capable a person is, but said person is the source of income to the university, so they have to walk a fine line between pandering too much to paying students and diluting the value of issued degrees and driving away sources of funding. If the University is instead funded based on the aggregate success of their graduates, it presents a very different motivation scheme.
Of course, that scheme might not pan out so well for liberal arts, where financially the result is likely not to be favorable.
systemd solves this problem in a rather elegant way.
My question was that 'structured text log requires cooperation of the logging program' was a tick against structured text, but I don't see how that argument does not equally apply against journald. You needn't lose the power of an indexed log file either. The one use case you put forth that can *not* be accomodated is compressed. Sealing, integrity checking, and indexed operations can be done through discrete storage of textual bulk data and binary metadata.
A simple command like "yum install syslog" will deal with that.
Small comfort if you find yourself trying to debug a problem on a non working system that had not yet done that step. There is a pretty large red flag that should be going up when a facility with nearly 100% append data intended for diagnostic purposes disregards the value of plain text logs.
you're just complaining because someone is trying to introduce a new standard and you never want to change anything, at all, ever.
I'm saying charging forward without any significant regard for adequate backwards compatibility is lunacy. Also, any advance that changes things in an incompatible way needs to be weighed carefully for benefit versus cost. On two fronts I see systemd as problematic: neglecting optimal backwards compatibility 'just cause' and if we embrace that vision, then what are we getting in exchange? Not really that much in practical benefit (yes, journalctl can do all sorts of tricks that most people never even felt the need for).
use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows
Dealing with \r\n versus \n is *totally* different scale than this. Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r'). EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.
And on modern systems, xz is commonplace as well.
My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.
No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).
I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation. I still would be in a fix despite having all the filesystem and block device wrangling required to get at the files.
That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.
Oh, I'm glad you can tell me what I know. I have to support a wide variety of systems, thousands of servers, I don't get the luxury of supporting only one version or even one distribution of linux or even just linux. Things like systemd exacerbate the problem of managing a heterogeneous environment where versions, distros, and platform can vary greatly. Things aren't rosy in that situation to begin with, but that's no excuse to take liberties to make things even worse when a better thought out scheme would still work.
Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way)
How is that different between journald and structured text logs? systemd also requires someone do the effort to make loggers play nice with it. If you've done the work to create an API through which 'good little boys and girls' will log through that to allow structure to be known, you can make the text file readily available alongside/in conjunction with binary metadata. You say 'syslog will do that automatically', but the target clearly is to discourage that from being the case (Fedora no longer runs rsyslog by default).
I realized that systemd's logging is far superior to any existing simple text logging.
I accept that is the case, but the approach threw out the baby with the bathwater. They could have maintained first class support for plaintext data either alongside or indexed by their binary blobs. I have used journalctl and it does have theoretically useful features. I have to say that, in practice, I've never found myself in particular need for what journalctl has added and only have used it to see that I could do it. There wouldn't have been a downside. They would have had the capabilities and performance they wanted, and the cases where an utterly trivial to read chunk of data would still be preserved.
If you have a cellphone with an NFC reader, then you don't *need* a physical 'bitcoin' to do bitcoin. If you call out having a cell phone to verify bitcoin transaction as too onerous, and therefore you need physical currency, then *you don't get to claim to have a free verification facility*. It's either cellphones are a trivial requirement and therefore you wouldn't need the physical currency, or cellphones are too big a burden and you can't verify the benefit of a bitcoin backed physical currency. You can't change your opinion on the availability of cell phones in the middle of explaining your stance just because a consistent opinion would unravel that stance.
That is the perspective even after hypothetically accepting the premise that bitcoin is the optimal underlying scheme. As someone who additionally rejects that premise, I'll say that while the current state of the credit card processing is pathetic, the answer is not going to bitcoin. Bitcoin brings a whole lot of bad with the good (at least the controlling interest to watch for corruption/abuse in Fiat currencies is a knowable thing, unlike Bitcoin where an abusive interest is possible, but can be more easily be hidden). In this specific case, if we accept the same infrastructure required for bitcoin to be viable (ubiquitous secure network-capable compute devices), then that same infrastructure could be applied to improve the security of credit card payment systems (abolish passing around a wide-open account number in favor of a more discretionary system where each transaction only provides a vendor what the vendor needs to authorize that one transaction for one specific amount).
Actually, I would complain if the currently active log file were gzipped. It's a needless impediment to read the files. Besides, once a developer has said 'gzip' the files, then they decide 'well, I can bzip them', then later 'oh, well,.lzma is good', then 'oh, use xz'.. This is the sort of situation that systemd sets up: a treadmill where diagnostic environments must match runtime environments or else.
When Linux systems all
This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world, and now systemd systems will break from that strategy.
Just because you *can* do something doesn't mean it should be done. Just because this is one way at getting to more sophisticated log analysis infrastructure doesn't mean there is not a better way which would have made everyone happy.
With a boot media it is a piece of cake to read the journald log files.
My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of those projects have to be aware and pick up updates. I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.
It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling. The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.
I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.
The point being that boot time is the most *visible* benefit and the rest of the benefit is dubious at best. It's interesting to see people create strawmen of complexity. In one case, they went through someone who got permission denied in error_log for apache and then understood to check permissions and selinux context. They then manufactured a straw man of someone confused by that doing service httpd status to see if it was running (who the hell get's http error 401 and wonders if the httpd service is running at all), who then looks at apache log, see file permission based error, and then goes to/var/log/messages. They say how with all this magic, they run status on the service and sees related messages (of course they conveniently avoiding having the general volume of log entries that would betray how awkward that is).
It's all the problem of people who do this for a living instead of a means to an end. It's easy to completely lose perspective when you spend too much time overthinking things. The best designs are really done by people with another job to do and wanting the least fuss and muss out of these sorts of things.
The problems with it include an obsession with APIs
Incidentally, this also means they align more closely with Microsoft thinking than traditional Unix thinking. At some point I wish these people would just accept they want Windows and go with Windows and leave Linux alone.
Slashdot Mirror
moving people into STEM that would otherwise work in lower paid occupations.
While I can agree that the perspective is a bit protectionist, that would not pan out that way. Generally speaking, improving wages overall is either not going to happen, or happen because of inflation. While very rarely is something a zero sum game in economics, it also is the case that it doesn't at least somewhat behave like a zero sum situation. It's not necessarily a bad thing for society in general, but one should not pretend for a second that such moves would magically enable everyone to get six-figure standard of living.
Though I'm not usually dealing with Microsoft platforms, I have enough experience with it to consider classifying it as 'legacy' in any sort of universal way an odd proposition. It is after all *the* first-party supported development framework for Microsoft platforms, very much continuing to be supported and developed by a pretty important market force (like it or not).
Of course 'Legacy' is mostly in the eye of the beholder. About the only place 'Legacy' seems to have unambiguous meaning is within a single development organization replacing/phasing out projects they control. COBOL continues to see pretty significant deployments and is actively being enhanced, though most people in the industry would consider that 'Legacy'. Similar story for Fortran. A number of languages that don't get so much 'glory' these days continue to play important roles in particular segments and continue to be developed. There are those that would consider PHP 'legacy' and others just moving onto the platform. If you try to name a platform that by popular opinion is almost certainly totally 'Legacy' you'll probably discover not only some groups doing new development in the language, but some companies or projects actually continuing to enhance the language for others. Basically, if you can remember it, it by some definition is probably still alive.
To say it's 'export controlled' is an oversimplification of the restrictions around working with those nations.
But in simple terms, this is about *contributors*, not downloading. And if it weren't an issue, then Fedora people wouldn't be trying to game it for plausible deniability (which of course doesn't work when you say "Hey everyone, I want to be able to claim plausible deniability so could you just omit some information so I can do that?"
While I agree that a government is almost certainly not behind this and thoughts that it is are people thinking a bit too much of BitCoin. That said, hypothetically I could see why a government would choose an underhanded way to bring down something like this compared to overt regulation.
Consider that bitcoin is in no small part driven by people fanatically thinking fiat currency is the devil (for some very literally calling the dollar the mark of the beast) and that gold standard or something like that is 'the' answer to all that ails any economy. Explicitly banning it bears the risk of inducing the supporters to say 'see, told you so!' (even though there are very practical reasons to not let it get carried away, the reasons are sufficiently complicated and nuanced that it would be hard to simply explain).
Of course, knowing precisely why an unregulated currency of this nature is a bad idea would leave the opportunity for a government to cause it to collapse by exploiting those flaws. Most likely the flaws are just naturally being exploited because you don't have to give crooks a big reason to be crooks, but it is a strategy that might be more effective than blanket laws.
no utilities of your own written specifically for this purpose.
Why not? That is *precisely* what wolfram did here. He designed the 'language' and decided 'gee it would be nice to have a first class function for travelling salesman', and then when he goes to demo, he whips that out to say 'look at this obscure capability omitted from most languages'. This may be useful, but being excited around the linecount is not something compelling in this case, as it shows no particularly exciting grammer/syntax stuff, just that Wolfram deemed 'travelling salesman' a problem worthy of being a first class function in the namespace.
Pretty much anyone can submit an IETF RFC if they really want. The existence of a draft does not guarantee a ratified version will exist someday.
For another, it could be much worse. There is explicit wording at least here about seeking consent from the user and allowing opt-out even in the 'captive' case, as well as notifying the actual webserver of this intermediary, and that the intermediary must use a particular keyusage field meaning that some trusted CA has explicitly approved it (of course, the CA model is pretty horribly ill-suited for internet scale security, but better than nothing). Remember how Nokia confessed they silently and without consent had their mobile browser hijack and proxy https traffic without explicitly telling the user or server? While something like this being formalized wouldn't prevent such a trick, it would be very hard to defend a secretive approach in the face of this sort of standard being in the wild.
Keep in mind that in a large number of cases in mobile, the carriers are handing people the device including the browser they'll be using. A carrier could do what Nokia admits to in many cases without the user being the wiser and claim the secretive aspect is just a side effect today. If there was a standard clearly laying out that a carrier or mobile manufacturer should behave a certain way, that defense would go away.
I would always elect the 'opt out' myself, but I'd prefer anything seeking to proxy secure traffic be steered toward doing things on the up and up rather than pretending no one will do it and leaving the door open for ambiguous intentions.
Even if it did need to have something like IR cameras to observe IR leds in the headset (or vice-versa, as the Wii did), I don't think it would be too bad.
They have gyroscopic in there already. That's how they can do yaw and such. Still does nothing to help you with linear movement.
It's a big commitment to strap a giant, heavy device on your face with 3+ cables to your PC
Granted, but then again, a lot of particular prominent, even more special purpose successes require a pretty big commitment. Rock band did well and no one is going to claim it's trivial to whip out the guitars and drumset. Granted their success did not endure, but primarily because the experience lacked sufficient variety, it did show people were committed to go through some hoops. Similarly, *really* sitting down to enjoy a feature length movie requires some commitment (doing so without commitment is possible, but much less enjoyable.
there aren't many games in the Steam Store that support VR today
And there weren't many games that supported accelerated 3D graphics when 3dfx voodoo came out. Being too discouraged by that leads to a chicken and egg situation. It's probably also off putting that the set of available titles are at best adaptations of existing games or very basic things. The reason being that the quality games take longer and as such are still in progress (Star Citizen is one I'm really looking forward to). Crystal Cove demonstrates they will have capabilities the dev kits aren't even equipped to help publishers prepare for yet. Oculus is doing the only thing that might have a chance, building up a lot of excitement and coming in at an approachable price point to try to break the chicken and egg situation.
Having your eyes so close to the screens means the display is effectively very low resolution.
This is one area that has me pretty worried and waiting (that and the availability of good positional sensing). I'm really hoping they will be able to use at least a 2560x1440 OLED display (thanks to the mobile resolution pissing contest, Samsung looks ready to announce a shipping product with 2560x1440 at 5.2", 560 ppi seems very promising to construct a display out of, even if magnified).
VR is a surprisingly anti-social hobby, even by gamer standards
Very, very rarely is gaming remotely entertaining to mere observers. A lot of very popular things are *always* equally anti-social (texting, reading books, listening to music on headphones, pretty much doing *anything* on a smartphone or even tablet, laptop, or computer).
Notice how quickly we get into geez-this-is-a-lot-of-equipment territory.
The same can be true of racing or flying games, but that doesn't stop the vast majority of people making do with simpler controls. Just because you *can* take things very far at a very high price, doesn't mean you have to. The external tracking of the head is going to be baked into the headset cost (and not that expensive, as Kinect has shown) Headphones are straightforward as is positional audio in the headphone situation. Beyond eyewear and headphones, things get optional pretty fast. Wiimote-grade tracking for hands I certainly see as a big value add, but things start falling off real fast beyond that (the treadmill I'm skeptical would do anything to pull me that much more in as I think it would still feel very very off, but would wear me out greatly).
They have accelerators in the headset. It doesn't do much good when at times the head can move at constant velocity. For sensing gravity and rotational movement, it works well, but translation movement is impossible to do reliably with accelerators lacking any sort of frame of reference.
I think the really difficult thing to overcome is when there truly is a labor surplus. Still a need for labor and particularly like you say, labor that not enough people 'just want' to do and particularly jobs almost anyone could do given a near trivial amount of training, but not enough demand to keep everyone meaningfully occupied.
Say hypothetically you are facing a situation that would mean massive unemployment, but realistically you could feed, clothe, shelter, and provide health care for everyone. But you still need people like delivery drivers. So either you provide all the fundamental needs for the unemployed and have a hard time finding people to do delivery work, or you resign society to screwing over the unemployed.
Of course, I think a key flaw that leads to this situation is the bad assumption that the choices are either 40 hours of work/week or 0 hours of work/week. A less ambitious goal might be to have more people working but for fewer hours. At least in the US, the stack is very heavily stacked against this evolution. The current healthcare situation is the worst of both worlds. When they first started talking health care reform, I imagined foolishly that we would be put on a path where one's employer did not have anything to do with coverage. Instead, it doubles down on that and as a result people are getting fewer hours, but without the health care. For such a goal to move forward, the 'magic' around 40 hrs/week has to go away.
Wealth stops being a concern for people once they're making over $70,000 a year.
While I agree there is more to motivation than money, that statement is just simply wrong. There was one dubious study that claimed that $75k maxed out 'happiness'. People still fret about acquiring compensation to put to some personal use well beyond $75k. Maybe somewhere up in the millions of dollars the dollar amount becomes more of a 'high score' than something to exchange for goods/services, but it's definitely not at $70k.
Good luck collecting on that clause when the student is in another country.
In all fairness, the same can apply to a loan. If you are in a country whose laws do not recognize your liability to your previous government, they likely don't recognize your liability for the loan. I think that the list of nations where that would work is pretty short and many of which are not exactly places you'd want to be.
While I am not sure how I feel about such a thought, he does present an interesting perspective. University in many cases presents a conflict of interest. An aspect of university is to prove to other people how capable a person is, but said person is the source of income to the university, so they have to walk a fine line between pandering too much to paying students and diluting the value of issued degrees and driving away sources of funding. If the University is instead funded based on the aggregate success of their graduates, it presents a very different motivation scheme.
Of course, that scheme might not pan out so well for liberal arts, where financially the result is likely not to be favorable.
*about* the same amount of ligth
I think the delta because of lunar eclipses counts in the 'about' neighborhood.
So you need to install extra tools... I don't see how that's different.
Those aren't extra, they come with windows.
And besides, how do you grep through Unix logfiles on Windows anyway? Oh yeah, install extra third-party tools from somewhere....
Actually, Windows comes with servicable grep equivalent out of the box, but that's not really the use case I care most about.
There's nothing sacrosanct about ASCII, it just happens to be the most popular encoding,
*EVERYTHING* for the last several decades can translate ASCII to a human consumable form. That's pretty damn significant to ignore.
xz performs better than gzip; that alone justifies its use. It's not like it takes a lot of hard drive space.
My point was being too aggressive about switching between technologies adds a lot of complexity to trying do support a mixed environment.
That's why you don't use ancient systems to work on newer systems.
CentOS 6 is the *current* version. If you install CentOS *today* that's what you get.
systemd solves this problem in a rather elegant way.
My question was that 'structured text log requires cooperation of the logging program' was a tick against structured text, but I don't see how that argument does not equally apply against journald. You needn't lose the power of an indexed log file either. The one use case you put forth that can *not* be accomodated is compressed. Sealing, integrity checking, and indexed operations can be done through discrete storage of textual bulk data and binary metadata.
A simple command like "yum install syslog" will deal with that.
Small comfort if you find yourself trying to debug a problem on a non working system that had not yet done that step. There is a pretty large red flag that should be going up when a facility with nearly 100% append data intended for diagnostic purposes disregards the value of plain text logs.
you're just complaining because someone is trying to introduce a new standard and you never want to change anything, at all, ever.
I'm saying charging forward without any significant regard for adequate backwards compatibility is lunacy. Also, any advance that changes things in an incompatible way needs to be weighed carefully for benefit versus cost. On two fronts I see systemd as problematic: neglecting optimal backwards compatibility 'just cause' and if we embrace that vision, then what are we getting in exchange? Not really that much in practical benefit (yes, journalctl can do all sorts of tricks that most people never even felt the need for).
use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows
Dealing with \r\n versus \n is *totally* different scale than this. Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r'). EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.
And on modern systems, xz is commonplace as well.
My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.
No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).
I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation. I still would be in a fix despite having all the filesystem and block device wrangling required to get at the files.
That is just a pathetic excuse, and you know it too. It is a 5 minute job make a Linux distro boot from a USB key. There are plenty of easy GUI tools to that, and it can even been done from a MS-Windows machine.
Oh, I'm glad you can tell me what I know. I have to support a wide variety of systems, thousands of servers, I don't get the luxury of supporting only one version or even one distribution of linux or even just linux. Things like systemd exacerbate the problem of managing a heterogeneous environment where versions, distros, and platform can vary greatly. Things aren't rosy in that situation to begin with, but that's no excuse to take liberties to make things even worse when a better thought out scheme would still work.
Feeble attempts have been made to make structured text log files, but the goal remained elusive for two reasons; it required the cooperation from all those making programs that wrote in the log (do it this way)
How is that different between journald and structured text logs? systemd also requires someone do the effort to make loggers play nice with it. If you've done the work to create an API through which 'good little boys and girls' will log through that to allow structure to be known, you can make the text file readily available alongside/in conjunction with binary metadata. You say 'syslog will do that automatically', but the target clearly is to discourage that from being the case (Fedora no longer runs rsyslog by default).
I realized that systemd's logging is far superior to any existing simple text logging.
I accept that is the case, but the approach threw out the baby with the bathwater. They could have maintained first class support for plaintext data either alongside or indexed by their binary blobs. I have used journalctl and it does have theoretically useful features. I have to say that, in practice, I've never found myself in particular need for what journalctl has added and only have used it to see that I could do it. There wouldn't have been a downside. They would have had the capabilities and performance they wanted, and the cases where an utterly trivial to read chunk of data would still be preserved.
If you have a cellphone with an NFC reader, then you don't *need* a physical 'bitcoin' to do bitcoin. If you call out having a cell phone to verify bitcoin transaction as too onerous, and therefore you need physical currency, then *you don't get to claim to have a free verification facility*. It's either cellphones are a trivial requirement and therefore you wouldn't need the physical currency, or cellphones are too big a burden and you can't verify the benefit of a bitcoin backed physical currency. You can't change your opinion on the availability of cell phones in the middle of explaining your stance just because a consistent opinion would unravel that stance.
That is the perspective even after hypothetically accepting the premise that bitcoin is the optimal underlying scheme. As someone who additionally rejects that premise, I'll say that while the current state of the credit card processing is pathetic, the answer is not going to bitcoin. Bitcoin brings a whole lot of bad with the good (at least the controlling interest to watch for corruption/abuse in Fiat currencies is a knowable thing, unlike Bitcoin where an abusive interest is possible, but can be more easily be hidden). In this specific case, if we accept the same infrastructure required for bitcoin to be viable (ubiquitous secure network-capable compute devices), then that same infrastructure could be applied to improve the security of credit card payment systems (abolish passing around a wide-open account number in favor of a more discretionary system where each transaction only provides a vendor what the vendor needs to authorize that one transaction for one specific amount).
Actually, I would complain if the currently active log file were gzipped. It's a needless impediment to read the files. Besides, once a developer has said 'gzip' the files, then they decide 'well, I can bzip them', then later 'oh, well, .lzma is good', then 'oh, use xz'.. This is the sort of situation that systemd sets up: a treadmill where diagnostic environments must match runtime environments or else.
When Linux systems all
This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world, and now systemd systems will break from that strategy.
Just because you *can* do something doesn't mean it should be done. Just because this is one way at getting to more sophisticated log analysis infrastructure doesn't mean there is not a better way which would have made everyone happy.
With a boot media it is a piece of cake to read the journald log files.
My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of those projects have to be aware and pick up updates. I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.
It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling. The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.
I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.
The point being that boot time is the most *visible* benefit and the rest of the benefit is dubious at best. It's interesting to see people create strawmen of complexity. In one case, they went through someone who got permission denied in error_log for apache and then understood to check permissions and selinux context. They then manufactured a straw man of someone confused by that doing service httpd status to see if it was running (who the hell get's http error 401 and wonders if the httpd service is running at all), who then looks at apache log, see file permission based error, and then goes to /var/log/messages. They say how with all this magic, they run status on the service and sees related messages (of course they conveniently avoiding having the general volume of log entries that would betray how awkward that is).
It's all the problem of people who do this for a living instead of a means to an end. It's easy to completely lose perspective when you spend too much time overthinking things. The best designs are really done by people with another job to do and wanting the least fuss and muss out of these sorts of things.
The problems with it include an obsession with APIs
Incidentally, this also means they align more closely with Microsoft thinking than traditional Unix thinking. At some point I wish these people would just accept they want Windows and go with Windows and leave Linux alone.