My wife's iPad Mini 2 continues to perfectly serve all her computer-related needs.
Give it a year. As the Mini 2 is no longer in support, more and more apps are going to be "upgraded" into not working with it, even though they would be perfectly capable. The iOS walled garden is no friend of the old device (I use an original Mini).
He's right, though -- it's a false economy to run renders on workstations. The primary goal of a workstation config is to increase worker productivity, which is not generally achieved by sheer grunt. Rendering is compute-intensive, and a very different value proposition. The manufacturers who convince people to constantly upgrade their workstations to get marginal performance improvements year after year are really just taking the proverbial. I suppose there's less profit in stable well-specced render server farms...
First - the Raspberry Pi doesn't have a battery for power.
Yes, but it is a very handy addition.
You can ADD that very easily - and guess what, it comes with battery management.
Really? Every time I've looked into it, the recommended solution is a USB powerpack (no power management). A couple of things like MoPi arrived pretty late in the game, but it takes up you GPIO, making it incompatible with various other add-ons. If the power management had been built in from the ground up (even if only a single pin was specced to initiate a low battery power down sequence), it wouldn't be a choice.
Consider this: what demographic is most likely to tinker and experiment? I'd say it's older children. But parents are giving kids tablets instead of fully-fledged PCs, so they won't have the same access to tinkering tools. Also, as the kids grow up in Tabletspace, they'll most likely become accustomed to tablet-like ways of working. And OK, being honest, a lot of tablet workflows are better than PC workflows, but mostly because they're not part of a continuum of change. Most major music and photo packages are still heavily-hacked versions of an analogue to the analogue world, and tablet workflows are designed not for people who know the task, but for people who know tablets. There's no reason we couldn't make similar workflows for PCs, but for wordprocessing, coding and the like, the PC workflow can't be replicated on the tablet.
I have an iPad that is not compatible with iOS 10. The browser is flaky, crashing frequently on some pretty simple websites, but no-one is allowed to give or sell me a browser that is stable. If I code an app and Apple doesn't like it, I can't sell it to anyone. Sounds pretty tightly locked down to me.
I will never understand why the Pi doesn't have onboard battery management. Without that, much of the most compelling usecases are denied us. This is why C.H.I.P. has so much potential. I'm personally considering putting an OLinuXino (another ARM-with-battery management SBC) inside the shell of a dead laptop as my next portable.
That's completely beside the point of the AC 4 levels up, which is that when the Steam client drops support for the OS -- so for example when Steam drops support for XP (if it hasn't already).
It's really quite irritating when you're having a conversation about X and someone comes in and starts arguing against Y. Try reading the conversation for a change.
When your hardware is no longer supported by MS, you have no choice (even some made-for-Windows 10 machines were obsoleted by the anniversary release).
First MS makes the OS to be crap on gaming and then it extorts developers to put their games into Windows store to get decent performance. Antitrust class action lawsuit is the next logical step.
Will it get as far as class action? I can easily see Steam attacking them single-handed.
Good union: Many trains in the UK still don't have retention toilets, and spread human waste on the tracks. The RMT union asked the rail companies to inoculate track workers against diseases spread by human faeces. The companies refused saying that they'd be fitting retention toilets in all trains within the next ten years, so it wasn't an issue. The RMT responded by threatening strike action. The companies paid for the inoculations. (I have a feeling there had actually been a case of cholera in one rail worker, so we're not just talking minor bugs here.)
Kensington-style laptop locks are not particularly secure. Their benefit is only that you can't casually lift a laptop on the way past -- you have to give them a good hard yank, and it is generally quite visible and often also audible. Most office jobs issue cable locks with laptops, but you'll be told not to leave your laptop locked to the desk overnight. The locks should only be used when you're going to leave the laptop for a short period of time (eg toilet break) in a place where several others can see it.
How important is performance on telling a light-bulb to switch on and off though? Timers for thermostats don't need even to-the-second response times, never mind microsecond accuracy. Traditional embedded devices need tight monitoring cycles, but "things" are generally pretty dumb devices all told.
Well, the whole Internet of Shit depends on C programmed Linux enabled ARM processors, so one could wish for it to be dying, but it is very unlikely.
Are we sure that's true? These Linux-enabled ARM processors are more powerful than the PC I was programming in interpreted languages at the turn of the century, and most of them are doing very simple things like turning heaters or lights on and off, which isn't computationally expensive. Small indy "things" are often built around the Raspberry Pi, because that's what the prototype was built on... and probably in Python. If I was building a garage door opener out of a computer with enough grunt to run four simultaneous games of Quake, I don't think I'd really care about optimising my code to that extent.
So I'm seeing more new pure C libraries being created now than I've seen in a very long time. Library developers know that their libraries will be usable from every language if they write it in pure C.
But that still marks a shift away from C in "macro" development. C's a good choice for small, self-contained chunks of code that are likely to be reused frequently, but the bulk of dev work is specialised glue logic for a particular app -- probably a Temple Run clone. Nobody's going to write a Temple Run clone in C.
It's a quite fascinating piece of work and baffling for someone like myself with a CS degree but no real understanding of semiconductors, so it's no surprise the journos couldn't really report well on it. A brief glance at the paper shows the researchers make no claims about this ever being a mainstream technology. I think they're doing the usual academic thing of just learning about possibilities for possibilities' sake. It seems to indicate fundamental properties in memoristor devices, but it's not "calculation in memory" because using it properly requires control circuitry, so it becomes just another type of processor.
The hardest part for any software that converts from straight to curly to get right are contractions with a leading quote: 'twas, 'tis, '12, and so forth. Especially in fiction and attempts at vernacular.
Exactly. It's a particular nuisance if you're embedding examples of another language and don't want the hassle of constantly changing language sentence after sentence (for example, if you're writing a worksheet for a foreign language class) and the other language has a lot of initial contractions.
Yes, but in order to use that to "comment out" multiple lines of code, you've got to indent each and every line of code that you're commenting out, which defeats the purpose of the exercise.
That's not true. Most editors have a notion of tab stops, and a tab does not "uncompress" to a specific number of spaces. In gedit, a tab character is a true tab -- by default it will leave up to 8 blank columns, moving to the next column that's directly after a multiple of eight. It's very different from just a number of spaces.
Yes, but the point here is that it's a semantic token that can be rendered as per personal preference, which would be a good thing. However, Python conventions favour spaces because people like to line up their continuation lines exactly (eg the continuation of a parenthetical expression should be indented at least one character beyond the parenthesis or bracket it is ruled by), which means either all spaces or a mixture of tabs and space... or at least it does until we abandon our collective love of dumb plaintext editors and start writing languages that demand that the editor parses code structure and renders the code itself.
Syntactic whitespace makes me twitch, too; but it neatly resolves many of the codestyle hubbub issues you see in other language environments.
If your editor helps you do the right thing, it's just an aesthetic whine, and shouldn't be worth arguing about.
...and there's my big problem with semantic whitespace: if it all comes down to needing the right editor, why bother with semantic whitespace in the first place?
Any decent code editor can match parentheses no problem at all, so why not have the editor parse the structure and handle the indentation automatically? That way everybody in the team can have the code set in the way that is most readable to them taking into account their screen size, coding style, visual impairments etc.
Yes, but you've got to remember that while Python has no end delimiter for code blocks, it does have a start delimiter --:. People try to spin it that a colon is a syntactic feature of the preceding statement, but that is merely playing semantics. It occurs everywhere an open brace would in C, Java etc.
The cost of donation is (almost) zero, because of the unit cost. MS make their profit off people and corporate/institutional bodies with money. Institutions without money are not a target market, so there is no opportunity cost in donating either.
My wife's iPad Mini 2 continues to perfectly serve all her computer-related needs.
Give it a year. As the Mini 2 is no longer in support, more and more apps are going to be "upgraded" into not working with it, even though they would be perfectly capable. The iOS walled garden is no friend of the old device (I use an original Mini).
He's right, though -- it's a false economy to run renders on workstations. The primary goal of a workstation config is to increase worker productivity, which is not generally achieved by sheer grunt. Rendering is compute-intensive, and a very different value proposition. The manufacturers who convince people to constantly upgrade their workstations to get marginal performance improvements year after year are really just taking the proverbial. I suppose there's less profit in stable well-specced render server farms...
First - the Raspberry Pi doesn't have a battery for power.
Yes, but it is a very handy addition.
You can ADD that very easily - and guess what, it comes with battery management.
Really? Every time I've looked into it, the recommended solution is a USB powerpack (no power management). A couple of things like MoPi arrived pretty late in the game, but it takes up you GPIO, making it incompatible with various other add-ons. If the power management had been built in from the ground up (even if only a single pin was specced to initiate a low battery power down sequence), it wouldn't be a choice.
Consider this: what demographic is most likely to tinker and experiment? I'd say it's older children. But parents are giving kids tablets instead of fully-fledged PCs, so they won't have the same access to tinkering tools. Also, as the kids grow up in Tabletspace, they'll most likely become accustomed to tablet-like ways of working. And OK, being honest, a lot of tablet workflows are better than PC workflows, but mostly because they're not part of a continuum of change. Most major music and photo packages are still heavily-hacked versions of an analogue to the analogue world, and tablet workflows are designed not for people who know the task, but for people who know tablets. There's no reason we couldn't make similar workflows for PCs, but for wordprocessing, coding and the like, the PC workflow can't be replicated on the tablet.
I have an iPad that is not compatible with iOS 10. The browser is flaky, crashing frequently on some pretty simple websites, but no-one is allowed to give or sell me a browser that is stable. If I code an app and Apple doesn't like it, I can't sell it to anyone. Sounds pretty tightly locked down to me.
I will never understand why the Pi doesn't have onboard battery management. Without that, much of the most compelling usecases are denied us. This is why C.H.I.P. has so much potential. I'm personally considering putting an OLinuXino (another ARM-with-battery management SBC) inside the shell of a dead laptop as my next portable.
Clearly intelligence is entirely optional on Slashdot.
That's completely beside the point of the AC 4 levels up, which is that when the Steam client drops support for the OS -- so for example when Steam drops support for XP (if it hasn't already).
It's really quite irritating when you're having a conversation about X and someone comes in and starts arguing against Y. Try reading the conversation for a change.
"Entirely" optional? No. It's optional for publishers. Mandatory for buyers.
When your hardware is no longer supported by MS, you have no choice (even some made-for-Windows 10 machines were obsoleted by the anniversary release).
First MS makes the OS to be crap on gaming and then it extorts developers to put their games into Windows store to get decent performance. Antitrust class action lawsuit is the next logical step.
Will it get as far as class action? I can easily see Steam attacking them single-handed.
Good union: Many trains in the UK still don't have retention toilets, and spread human waste on the tracks. The RMT union asked the rail companies to inoculate track workers against diseases spread by human faeces. The companies refused saying that they'd be fitting retention toilets in all trains within the next ten years, so it wasn't an issue. The RMT responded by threatening strike action. The companies paid for the inoculations. (I have a feeling there had actually been a case of cholera in one rail worker, so we're not just talking minor bugs here.)
Kensington-style laptop locks are not particularly secure. Their benefit is only that you can't casually lift a laptop on the way past -- you have to give them a good hard yank, and it is generally quite visible and often also audible. Most office jobs issue cable locks with laptops, but you'll be told not to leave your laptop locked to the desk overnight. The locks should only be used when you're going to leave the laptop for a short period of time (eg toilet break) in a place where several others can see it.
How important is performance on telling a light-bulb to switch on and off though? Timers for thermostats don't need even to-the-second response times, never mind microsecond accuracy. Traditional embedded devices need tight monitoring cycles, but "things" are generally pretty dumb devices all told.
Well, the whole Internet of Shit depends on C programmed Linux enabled ARM processors, so one could wish for it to be dying, but it is very unlikely.
Are we sure that's true? These Linux-enabled ARM processors are more powerful than the PC I was programming in interpreted languages at the turn of the century, and most of them are doing very simple things like turning heaters or lights on and off, which isn't computationally expensive. Small indy "things" are often built around the Raspberry Pi, because that's what the prototype was built on... and probably in Python. If I was building a garage door opener out of a computer with enough grunt to run four simultaneous games of Quake, I don't think I'd really care about optimising my code to that extent.
So I'm seeing more new pure C libraries being created now than I've seen in a very long time. Library developers know that their libraries will be usable from every language if they write it in pure C.
But that still marks a shift away from C in "macro" development. C's a good choice for small, self-contained chunks of code that are likely to be reused frequently, but the bulk of dev work is specialised glue logic for a particular app -- probably a Temple Run clone. Nobody's going to write a Temple Run clone in C.
Very concise and useful summary -- thanks!
It's a quite fascinating piece of work and baffling for someone like myself with a CS degree but no real understanding of semiconductors, so it's no surprise the journos couldn't really report well on it. A brief glance at the paper shows the researchers make no claims about this ever being a mainstream technology. I think they're doing the usual academic thing of just learning about possibilities for possibilities' sake. It seems to indicate fundamental properties in memoristor devices, but it's not "calculation in memory" because using it properly requires control circuitry, so it becomes just another type of processor.
The hardest part for any software that converts from straight to curly to get right are contractions with a leading quote: 'twas, 'tis, '12, and so forth. Especially in fiction and attempts at vernacular.
Exactly. It's a particular nuisance if you're embedding examples of another language and don't want the hassle of constantly changing language sentence after sentence (for example, if you're writing a worksheet for a foreign language class) and the other language has a lot of initial contractions.
if expression: action()
- that's perfect valid python.
Yes, but in order to use that to "comment out" multiple lines of code, you've got to indent each and every line of code that you're commenting out, which defeats the purpose of the exercise.
That's not true. Most editors have a notion of tab stops, and a tab does not "uncompress" to a specific number of spaces. In gedit, a tab character is a true tab -- by default it will leave up to 8 blank columns, moving to the next column that's directly after a multiple of eight. It's very different from just a number of spaces.
Yes, but the point here is that it's a semantic token that can be rendered as per personal preference, which would be a good thing. However, Python conventions favour spaces because people like to line up their continuation lines exactly (eg the continuation of a parenthetical expression should be indented at least one character beyond the parenthesis or bracket it is ruled by), which means either all spaces or a mixture of tabs and space... or at least it does until we abandon our collective love of dumb plaintext editors and start writing languages that demand that the editor parses code structure and renders the code itself.
Syntactic whitespace makes me twitch, too; but it neatly resolves many of the codestyle hubbub issues you see in other language environments.
If your editor helps you do the right thing, it's just an aesthetic whine, and shouldn't be worth arguing about.
...and there's my big problem with semantic whitespace: if it all comes down to needing the right editor, why bother with semantic whitespace in the first place?
Any decent code editor can match parentheses no problem at all, so why not have the editor parse the structure and handle the indentation automatically? That way everybody in the team can have the code set in the way that is most readable to them taking into account their screen size, coding style, visual impairments etc.
Yes, but you've got to remember that while Python has no end delimiter for code blocks, it does have a start delimiter -- :. People try to spin it that a colon is a syntactic feature of the preceding statement, but that is merely playing semantics. It occurs everywhere an open brace would in C, Java etc.
The cost of donation is (almost) zero, because of the unit cost. MS make their profit off people and corporate/institutional bodies with money. Institutions without money are not a target market, so there is no opportunity cost in donating either.