IoT devices will typically only have a few kB of RAM, so yes, it does matter. As a data point, I'm working with an ARM Cortex-M0 processor at the moment and it has a grand total of 128kB program memory (flash, so you can't use it for read/write data storage) and 16kB RAM. This is an entirely typical processor for this sort of IoT application.
You've just described Palm OS. The GUI's beautifully simple and would be perfectly adequate for virtually all tasks that the majority of users want to do.
Setting up a Palm OS emulator on a desktop and seeing how people react could be a fun experiment (though I'm not sure how most applications would cope with screens higher resolution than those found on real Palms).
Tynwald, the parliament of the Isle of Man (which is not part of the UK) has been running continuously since 979. While the Islandic parliament started in 930 it was abolished in 1800 and not reinstated until 1845.
For me, personally, I think programming languages should evolve more in the direction of mathematical notation
Like APL? This language, created at IBM in the 1960s, uses a mathematical notation and is very concise. APL programs therefore have a great tendency to be short but unreadable.
In the world of chip/FPGA design there's already a choice between visual and textual design. You can either draw a schematic showing how your blocks of logic are connected together or write some code in a language like Verilog, VHDL, or, my favourite, AHDL.
Beginners frequently start with visual design but soon find that any non-trivial system becomes a mess of nested blocks and wiring. With standard textual design you can build a structured design as you would for a normal program.
Most importantly, with a textual language you can parameterize objects (think #define and #ifdef) so that you can, for example, change a single constant in a top-level design file and have all the objects relink themselves to take account of the change. This isn't possible in a visual design language.
Visual design is something that only seems good to non-technical types who have no knowledge of structured code design. I imagine Bill mentioned it to make Microsoft seem innovative to these non-technical readers, I doubt it will ever be seriously used for programming.
My bad for not including references. I've never tried Dvorak for any length of time myself, but several studies (summarised in this magazine article (starting about 40% down the article)) show that the original study of the Dvorak layout, conducted by Dvorak himself, was very biased and that one would be better off doing extra QWERTY training than switching to Dvorak.
Of course, if Dvorak works for you (and many people report that the change reduces their RSI) then keep using it.
QWERTY wasn't designed to slow typing, it was designed to move the hammers for letters that would frequently be typed in sequence further apart. The further apart two hammers are, the faster they can be used in sequence since each hammer has to fall back less far before it is out of jamming range of the next hammer.
The utility of new layouts like Dvorak is dubious at best, giving only a small improvement after a lot of training, and causing problems when one has to switch between different machines with different keyboards.
Personally, I'll give up my clicky-clacky QWERTY IBM model M keyboard when they prise it from my cold, dead, fingers.
It depends on the barcode format used. Back in the early 90's at uni we had a project to write a barcode reader (on some random 68k based system). My software was able to read hand-drawn barcodes: it knew how many bars there were supposed to be and massaged the data from a barcode acquisition (removing small transitions, etc.) until it had the correct number of bars.
As long as the widths of thin and thick lines are sufficiently different barcodes can be very tolerant of dodgy printing.
Re:Core technology borrowed from MIT?
on
Techno Jacket
·
· Score: 1
As far as I'm aware (I didn't actually work on the jacket part of the wearables project (I'm working on next generation systems, and hence I can relax and read slashdot while those who were are running around like mad things dealing with the media)), no MIT technology has been used in the jacket.
The phone & mp3 players are standard Philips products and all the networking and the remote control were designed here (nr. London Gatwick, England).
Asher Hoskins
Philips Wearables Project
The BBC jacket picture (was: Re:Mod this guy up)
on
Techno Jacket
·
· Score: 1
Another inaccuracy in the BBC article... the red jacket is a very early prototype and doesn't look anything at all like the Philips/Levi jackets. The little keypad (bizarrely subtitled "Advanced technology could rob people of their privacy") is actually off the new jacket.
Off hand I don't know of an online site with a full picture of the jacket, I'll post it if I find one.
Inaccuracies in the BBC article
on
Techno Jacket
·
· Score: 5
The BBC online article contains a number of errors: the clothes do have a network, but it's for linking
together a phone, mp3 player, remote control, earpieces and microphone
and not so that 'the wearer [can] be fully connected to the world wide web
at all times' (although later versions may well be able to do this).
As for 'Disadvantages of the jackets include the possible implications of
network crashes and the effects of rainstorms on techno-clothing while being
worn.': the network in the current jackets is passive, and therefore there's
nothing to crash, and the
jackets are designed to be machine washed and so a little rain (or indeed
a great deal of hot soapy rain) really isn't going to bother them...
Nope, Beeb's (model B) only had 32k of RAM. The top 32k of the 6502 address space was ROM, with the top 16k being the OS (remarkably good considering its age, could do cool things like deal with asymmetric multi- processing as standard... in 1982!) and the 16k below that being paged ROMs. Up to sixteen 16k ROMs could share that space, with ROMs being paged in and out automatically by the OS as needed.
Later Beebs had RAM in some of the ROM slots so that you could easily upload/develop your own ROMs.
Slashdot Mirror
IoT devices will typically only have a few kB of RAM, so yes, it does matter. As a data point, I'm working with an ARM Cortex-M0 processor at the moment and it has a grand total of 128kB program memory (flash, so you can't use it for read/write data storage) and 16kB RAM. This is an entirely typical processor for this sort of IoT application.
Sounds like the Psion 7: http://newth.net/psion7/index.html
:-(
Excellent keyboard, colour screen, runs for ages on a charge, fast and lightweight EPOC operating system. Now discontinued.
You've just described Palm OS. The GUI's beautifully simple and would be perfectly adequate for virtually all tasks that the majority of users want to do.
Setting up a Palm OS emulator on a desktop and seeing how people react could be a fun experiment (though I'm not sure how most applications would cope with screens higher resolution than those found on real Palms).
Tynwald, the parliament of the Isle of Man (which is not part of the UK) has been running continuously since 979. While the Islandic parliament started in 930 it was abolished in 1800 and not reinstated until 1845.
Like APL? This language, created at IBM in the 1960s, uses a mathematical notation and is very concise. APL programs therefore have a great tendency to be short but unreadable.
In the world of chip/FPGA design there's already a choice between visual and textual design. You can either draw a schematic showing how your blocks of logic are connected together or write some code in a language like Verilog, VHDL, or, my favourite, AHDL.
Beginners frequently start with visual design but soon find that any non-trivial system becomes a mess of nested blocks and wiring. With standard textual design you can build a structured design as you would for a normal program.
Most importantly, with a textual language you can parameterize objects (think #define and #ifdef) so that you can, for example, change a single constant in a top-level design file and have all the objects relink themselves to take account of the change. This isn't possible in a visual design language.
Visual design is something that only seems good to non-technical types who have no knowledge of structured code design. I imagine Bill mentioned it to make Microsoft seem innovative to these non-technical readers, I doubt it will ever be seriously used for programming.
Dude! Does this mean I was wrong to backlight my heating pipes with neon and encase them in CNC-cut perspex? Nooooo!
Of course, inputting commands is rather trickier...
Of course, if Dvorak works for you (and many people report that the change reduces their RSI) then keep using it.
The utility of new layouts like Dvorak is dubious at best, giving only a small improvement after a lot of training, and causing problems when one has to switch between different machines with different keyboards.
Personally, I'll give up my clicky-clacky QWERTY IBM model M keyboard when they prise it from my cold, dead, fingers.
It depends on the barcode format used. Back in the early 90's at uni we had a project to write a barcode reader (on some random 68k based system). My software was able to read hand-drawn barcodes: it knew how many bars there were supposed to be and massaged the data from a barcode acquisition (removing small transitions, etc.) until it had the correct number of bars.
As long as the widths of thin and thick lines are sufficiently different barcodes can be very tolerant of dodgy printing.
The phone & mp3 players are standard Philips products and all the networking and the remote control were designed here (nr. London Gatwick, England).
Asher Hoskins
Philips Wearables Project
Off hand I don't know of an online site with a full picture of the jacket, I'll post it if I find one.
Asher Hoskins
Philips Wearables Project
(not official PR person, yadda, yadda...)
As for 'Disadvantages of the jackets include the possible implications of network crashes and the effects of rainstorms on techno-clothing while being worn.': the network in the current jackets is passive, and therefore there's nothing to crash, and the jackets are designed to be machine washed and so a little rain (or indeed a great deal of hot soapy rain) really isn't going to bother them...
There's a rather more accurate article in the Guardian online at: http://ww w.guardianunlimited.co.uk/Archive/Article/0,4273,4 051264,00.html
Asher Hoskins
Philips Wearables Project
(a engineer, not an official spokesman! go speak to Philips PR if you want one of those!)
Nope, Beeb's (model B) only had 32k of RAM. The top
32k of the 6502 address space was ROM, with the top
16k being the OS (remarkably good considering its age,
could do cool things like deal with asymmetric multi-
processing as standard... in 1982!) and the 16k below that
being paged ROMs. Up to sixteen 16k ROMs could share
that space, with ROMs being paged in and out automatically
by the OS as needed.
Later Beebs had RAM in some of the ROM slots so that
you could easily upload/develop your own ROMs.
Asher.