Right. We hear a lot about "DST all year round" or, up here, "permanent summertime". It doesn't sound as good if you call it "getting up an hour earlier in the winter".
Japanese chess is the most computationally expensive of the three, but Chinese chess is indeed more expensive than the European variant. Also, note that "shogi" and "xiangqi" are written using the same characters (give or take simplification) and there are different rules native to Japan, but the most complicated game is the most popular.
Maybe the OP thinks the Chinese game is more computationally difficult because they've read scientific papers that say this. I know I have. It has a larger board and games tend to run on for longer. There's also much less likelihood of a draw, so apparently equal positions will probably yield a result.
Note that in my experience, Chinese people don't believe this. The think the game foreigners play must be more difficult. I believe this is one reason they undervalue their own game and don't promote it internationally.
After thinking about this far too much, I've concluded that POSIX should go to some form of GMT that isn't UTC, either UT1 or UT2, whatever the difference is. It keeps the numeric timestamp meaningful: you can get the time and date most of us care about with basic arithmetic and no lookup tables. Future timestamps will work the same way. Unless you really need to know the current time in UTC, in which case you'll need a lookup table, which is simple enough as predictions are published that should be good enough. Software that cares about UTC can use lookup tables to give you the real time corresponding to your GMT timestamp, which means full leap second support for software that cares without burdening the hardware clock or software that doesn't care. And your historical timestamp might even record a leap second you didn't know about because your time zones files were out of date when you recorded it. No abrupt changes as we pretend UTC and GMT are really the same. No historical times that can't be represented.
If you really care about UTC, you can always set your clock to atomic time and use the "right" timezones the same way nobody does now and leave the rest of us alone.
Networking protocols can be designed to work if two devices pick different standards and end up being (shock!) up to a second different.
(I don't know how Microsoft are implementing the headline changes. I read the article and the article it links to, and they still gloss over the details.)
Python has reached its middle-aged bloat. There was plenty of saying "no" for the first ten years or so. It's now got a lot of features that are all useful for somebody, and a lot of cruft that's accumulated as the obvious way to do things has changed. It's becoming an advanced language for experts rather than a simple and versatile language that's quick to pick up. This isn't a unique problem and calling it poorly managed is unfair to the language designer. The time's ripe for a new language designer to come up with a new language that learns the lessons of the past two decades or so. I haven't seen it.
HTTP allows a MITM to run a virus scan and block malicious content. Arguments against HTTP assume ISPs are less trustworthy than random website owners. Which may be true in general, but that doesn't mean it needs to be fixed at the protocol level.
If we're talking protocols, though, secure content that's visible to a MITM but authenticated client-side (signed but not encrypted) is certainly possible. It would allow ISPs to run virus checkers (so viruses can't hide behind a Google certificate, by coming from a Google-hosted website, for example) and caching to save bandwidth, but stop malware and advert injection. And a sensible protocol would allow privacy where it's really needed. It's a shame Google is trying to reform HTTP but not putting any weight behind a proxy-aware HTTPS.
Like every engineering disaster, somebody found the problem, and failed to communicate its severity. In this case, they decided it wasn't a safety issue (cracks in a brand new bridge!) and left a voice mail with somebody else who was out of the office for a few days.
There's no substitute for risk assessments by fully qualified engineers, of course. But those engineers also need communication skills â" including persuasive skills. Engineers who can find somebody in authority and convince them to take action save lives.
There's nothing contradictory about Linux. No one praises it's GUI. They praise its customisability but that's as far as it goes
Oh, I do. I love the GUI. At least I love my GUI, centered around Openbox. It's the main reason I use Linux by choice instead of Windows or OS X. It's easy enough to get much the same command line on both of them, and with OS X it's basically already there, embedded in the dumbed-down OS X GUI. My GUI got like it is because I could customize it, so customisability is certainly part of the appeal. I have my own themes and I can move the themes and settings from one machine to another by copying a few text files. Openbox also gives me sloppy focus, multiple workspaces, keyboard control, and command line integration without much effort, and it's fast and runs on old hardware.
A lot of this can be done with Windows and OS X. All of it, technically, because you can install Openbox with an X server. And that's how I ended up working (even where I started using Openbox) but it's easier to install Linux and be done with it if you want a Linux GUI (like I do).
It's a shame Gnome was always reluctant to support other Window managers, and dropped them completely with Gnome3. It means the GUI I use is lacking a few features, like configuration screens for monitors and keyboard mappings. So if you want that you're back to Gnome or KDE or Unity. I assume somebody must praise them or they wouldn't have got to be the defaults.
Gnome2 was getting quite good, so it's possible MATE would do what I want. But I haven't tried it because, as a Linux user, I'm more interested in getting things done.
The article switches between talking about "Americans" and "people" as if the two are synonyms. I've noticed a lot of Americans think like this. I assume that Americans are the proper scope for the survey. So it's Americans who are too young to remember the cold war who have this idea that capitalism's a bad thing.
No, an estimate isn't a gamble. It only becomes a gamble if you treat it as a target or a promise, and commit resources to it. The real problem may be not allowing an estimate to change as more information comes in.
I don't know how long it takes to build the average house, but I'd guess between a week and a year. I'm sure people who build them all the time have a pretty good idea (along with the uncertainties) assuming some implicit context like where you're having the conversation. If you expect a mansion in the desert on a mountain to take the same amount of time, you're an idiot. Of course the estimate will change if there are unusual requirements. Another problem with software engineering is that it's full of idiots like this, so we get frightened of providing the estimate.
>>> import time >>> import random >>> chars = [chr(random.randint(0,255)) for each in range(1000000)] >>> stamp=time.time(); joined=''.join(chars); time.time()-stamp 0.11153912544250488
So that's 1/9 of a second on a not very fast laptop. You can try it yourself. Obviously not as fast as C++ but not horrible.
I wondered what this "Xinhau" was. An Indian rip off of Xinhua? But, no, it's somebody who can't spell a word correctly when it's sitting in front of them. Reminds me of some of my students, in fact.
To lose changes to a single file: git checkout foo. To lose changes to all files: git reset --hard . To see changes brought in by a revision: git show revision (unless it's a merge).
Types certainly matter, and Python has types. Yes, feeding the wrong type into a function probably won't work. It'll raise an exception and you'll see a traceback that helps you to fix your code.
If you want to check the types that are supplied to a function, you can do it with assertions. You can even go further and check the things going in have the properties you want. Type checks are a crude form of precondition. A function that expects a tuple will probably work with a list. A function that works with an iterable can accept a whole load of types without all the constipation of an explicitly coded interface to declare for all of them.
If you want the type errors picked up before you execute the code, you might be in luck. You could use the assertions, although I don't know of any tools that do this. There's also a convention for type specifications in docstrings. And official support for function annotations:
None of which addresses static typing as such, which says that after assigning an integer to a variable, you shouldn't be able to reassign it as a float.
There are, still, real advantages to static typing and languages that give you those benefits with type inference, so you don't have to put type declarations all over the place. There are also languages with better generics than void * in C or Object in Java. (C++ and Java are even two of them). Mixing the good features of Python with a good static typing system would certainly be a good thing.
Oh, and I've been programming for a good deal longer than 20 years. I can appreciate different languages for working in different ways.
It's Debian with a coherent desktop built around Openbox, and an installer, and maybe some other choices different to the Debian defaults. It uses the Debian repositories as well as its own and even declares itself "Debian GNU/Linux" when you SSH in.
I happen to prefer the LXDE desktop now I can turn the bits I don't want off. I can understand the argument that Crunchbang isn't as important as it was. But enough people will prefer the Crunchbang style that they'll keep it going with a different name.
Slashdot Mirror
Right. We hear a lot about "DST all year round" or, up here, "permanent summertime". It doesn't sound as good if you call it "getting up an hour earlier in the winter".
Japanese chess is the most computationally expensive of the three, but Chinese chess is indeed more expensive than the European variant. Also, note that "shogi" and "xiangqi" are written using the same characters (give or take simplification) and there are different rules native to Japan, but the most complicated game is the most popular.
Maybe the OP thinks the Chinese game is more computationally difficult because they've read scientific papers that say this. I know I have. It has a larger board and games tend to run on for longer. There's also much less likelihood of a draw, so apparently equal positions will probably yield a result.
Note that in my experience, Chinese people don't believe this. The think the game foreigners play must be more difficult. I believe this is one reason they undervalue their own game and don't promote it internationally.
After thinking about this far too much, I've concluded that POSIX should go to some form of GMT that isn't UTC, either UT1 or UT2, whatever the difference is. It keeps the numeric timestamp meaningful: you can get the time and date most of us care about with basic arithmetic and no lookup tables. Future timestamps will work the same way. Unless you really need to know the current time in UTC, in which case you'll need a lookup table, which is simple enough as predictions are published that should be good enough. Software that cares about UTC can use lookup tables to give you the real time corresponding to your GMT timestamp, which means full leap second support for software that cares without burdening the hardware clock or software that doesn't care. And your historical timestamp might even record a leap second you didn't know about because your time zones files were out of date when you recorded it. No abrupt changes as we pretend UTC and GMT are really the same. No historical times that can't be represented.
If you really care about UTC, you can always set your clock to atomic time and use the "right" timezones the same way nobody does now and leave the rest of us alone.
Networking protocols can be designed to work if two devices pick different standards and end up being (shock!) up to a second different.
(I don't know how Microsoft are implementing the headline changes. I read the article and the article it links to, and they still gloss over the details.)
Who's with me?
Python has reached its middle-aged bloat. There was plenty of saying "no" for the first ten years or so. It's now got a lot of features that are all useful for somebody, and a lot of cruft that's accumulated as the obvious way to do things has changed. It's becoming an advanced language for experts rather than a simple and versatile language that's quick to pick up. This isn't a unique problem and calling it poorly managed is unfair to the language designer. The time's ripe for a new language designer to come up with a new language that learns the lessons of the past two decades or so. I haven't seen it.
HTTP allows a MITM to run a virus scan and block malicious content. Arguments against HTTP assume ISPs are less trustworthy than random website owners. Which may be true in general, but that doesn't mean it needs to be fixed at the protocol level.
If we're talking protocols, though, secure content that's visible to a MITM but authenticated client-side (signed but not encrypted) is certainly possible. It would allow ISPs to run virus checkers (so viruses can't hide behind a Google certificate, by coming from a Google-hosted website, for example) and caching to save bandwidth, but stop malware and advert injection. And a sensible protocol would allow privacy where it's really needed. It's a shame Google is trying to reform HTTP but not putting any weight behind a proxy-aware HTTPS.
Like every engineering disaster, somebody found the problem, and failed to communicate its severity. In this case, they decided it wasn't a safety issue (cracks in a brand new bridge!) and left a voice mail with somebody else who was out of the office for a few days.
There's no substitute for risk assessments by fully qualified engineers, of course. But those engineers also need communication skills â" including persuasive skills. Engineers who can find somebody in authority and convince them to take action save lives.
Somebody should really invent a thermostat that cuts in automatically when the temperature goes below a certain level.
embrass v. to embarrass with an embrace
If you need rebase in Subversion, there is a Python script that can do it https://bitbucket.org/x31eq/om...
If only there were other countries where people could use phones
Or, again on Firefox, View | Page Style | No Style
If you believe progress in technology, it's depressing how many sites this improves. Including Slashdot.
Oh, I do. I love the GUI. At least I love my GUI, centered around Openbox. It's the main reason I use Linux by choice instead of Windows or OS X. It's easy enough to get much the same command line on both of them, and with OS X it's basically already there, embedded in the dumbed-down OS X GUI. My GUI got like it is because I could customize it, so customisability is certainly part of the appeal. I have my own themes and I can move the themes and settings from one machine to another by copying a few text files. Openbox also gives me sloppy focus, multiple workspaces, keyboard control, and command line integration without much effort, and it's fast and runs on old hardware.
A lot of this can be done with Windows and OS X. All of it, technically, because you can install Openbox with an X server. And that's how I ended up working (even where I started using Openbox) but it's easier to install Linux and be done with it if you want a Linux GUI (like I do).
It's a shame Gnome was always reluctant to support other Window managers, and dropped them completely with Gnome3. It means the GUI I use is lacking a few features, like configuration screens for monitors and keyboard mappings. So if you want that you're back to Gnome or KDE or Unity. I assume somebody must praise them or they wouldn't have got to be the defaults.
Gnome2 was getting quite good, so it's possible MATE would do what I want. But I haven't tried it because, as a Linux user, I'm more interested in getting things done.
You can enable IPv6 privacy extensions in Network Manager. Any conspiracy powerful enough to prevent you doing this would have outlawed IPv4 long ago.
The article switches between talking about "Americans" and "people" as if the two are synonyms. I've noticed a lot of Americans think like this. I assume that Americans are the proper scope for the survey. So it's Americans who are too young to remember the cold war who have this idea that capitalism's a bad thing.
You may put bugs in your init scripts if you edit them with emacs, but you'll find everything works a lot better if you switch to vi.
No, an estimate isn't a gamble. It only becomes a gamble if you treat it as a target or a promise, and commit resources to it. The real problem may be not allowing an estimate to change as more information comes in.
I don't know how long it takes to build the average house, but I'd guess between a week and a year. I'm sure people who build them all the time have a pretty good idea (along with the uncertainties) assuming some implicit context like where you're having the conversation. If you expect a mansion in the desert on a mountain to take the same amount of time, you're an idiot. Of course the estimate will change if there are unusual requirements. Another problem with software engineering is that it's full of idiots like this, so we get frightened of providing the estimate.
Berlin is in the eastern hemisphere
So that's 1/9 of a second on a not very fast laptop. You can try it yourself. Obviously not as fast as C++ but not horrible.
I wondered what this "Xinhau" was. An Indian rip off of Xinhua? But, no, it's somebody who can't spell a word correctly when it's sitting in front of them. Reminds me of some of my students, in fact.
To lose changes to a single file: git checkout foo. To lose changes to all files: git reset --hard . To see changes brought in by a revision: git show revision (unless it's a merge).
Types certainly matter, and Python has types. Yes, feeding the wrong type into a function probably won't work. It'll raise an exception and you'll see a traceback that helps you to fix your code.
If you want to check the types that are supplied to a function, you can do it with assertions. You can even go further and check the things going in have the properties you want. Type checks are a crude form of precondition. A function that expects a tuple will probably work with a list. A function that works with an iterable can accept a whole load of types without all the constipation of an explicitly coded interface to declare for all of them.
If you want the type errors picked up before you execute the code, you might be in luck. You could use the assertions, although I don't know of any tools that do this. There's also a convention for type specifications in docstrings. And official support for function annotations:
https://www.python.org/dev/pep...
None of which addresses static typing as such, which says that after assigning an integer to a variable, you shouldn't be able to reassign it as a float.
There are, still, real advantages to static typing and languages that give you those benefits with type inference, so you don't have to put type declarations all over the place. There are also languages with better generics than void * in C or Object in Java. (C++ and Java are even two of them). Mixing the good features of Python with a good static typing system would certainly be a good thing.
Oh, and I've been programming for a good deal longer than 20 years. I can appreciate different languages for working in different ways.
It's Debian with a coherent desktop built around Openbox, and an installer, and maybe some other choices different to the Debian defaults. It uses the Debian repositories as well as its own and even declares itself "Debian GNU/Linux" when you SSH in.
I happen to prefer the LXDE desktop now I can turn the bits I don't want off. I can understand the argument that Crunchbang isn't as important as it was. But enough people will prefer the Crunchbang style that they'll keep it going with a different name.
If you want a systemd-less Debian, go make a systemd-less Debian. Make it everything you think crunchbang should have been. Nobody's stopping you.