Re: Back-door?
Yes it does have a backdoor - it's a 4-panel, white oak affair with glass top panes and gold fittings.
192 publicly visible posts • joined 7 May 2010
One of my old bosses was known to use cheesy metaphors in every meeting and presentation. One day he stuck his head out of his office and, in a very casual manner, asked me to 'take a look' at his IBM PC-XT in about 10 mins as the 'whole lot has gone up in smoke' and he'd be out for a meeting.
10 minutes later, I sauntered into his empty office to encounter a smoke-filled room and a big, melty, burnt hole in the top of his CGA colour ('Luxury!') monitor.
Um..OK..
I had the pleasure of visiting a building where the architects managed to design the server room with a FOUR FOOT flloor void rather than the desired 4 inches. Somehow this cock-up of NASA dimensioning proportions made it through all checks and that's how the building was constructed.
By the time the building was completed and occupied, the data centre looked 'normal'... until you lifted a floor panel and stared into the void; this was one data centre where you **really** had to be careful if you left a floor panel out of place! There was so much space below the floor that the IT guys had installed servers down there - as my knees and back dscovered when I turned up to fit a new Ethernet card and was told which tile to lift to start my crawl.
> advances which aid or assist users who eyesight and/or coordination is failing.
A nice pair of Apple iEyes inserts...
Direct Cortex Inject (DCItm) for pure digital visiion, and only the occasional, discrete advertisement in the corner of your vision (unless you upgrade to the ad-free subscription package).
"IoT mostly seems to be rich people taking dumb appliances adding data mining technology for the poor unwashed masses and then eventually charging far more to buy the original dumb appliance again that doesn't spy on you (for them of course)."
I call this "The bacon strategy":
* Once upon a time, bacon was just cured/smoked pork with nothing added; it tasted fine and cooked well.
* Then some bright spark worked out how to inject water into the process and sell a crappier version of bacon for greater profit.
* Over time, this crappy, water-laden bacon became the norm and everyone just accepted the state of play because they grew up with the shitty stuff.
* Next, the bacon companies started to sell 'traditional' bacon again with no added water, but because it was now 'special', they charged extra for a now-considered-premium product.
Great airline; the last (and I really mean LAST) time I flew with them, they upgraded my direct San Francisco to London Heathrow flight to include an additional 8 hours at the airport and a free visit to Dulles Washington. I effectively gained a WHOLE DAY of extra traveling for no extra charge and skipped a Monday at work; what's not to like!?
I am waiting for your call - I'm cheap too!
--------
pasneta.pas
this file contains the function and procedure declarations
for the TurboPascal/Advanced NetWare interface}
type
Strvar = String[52];
function xtndopn(var Mode, Handle: Integer;var Filename: Strvar): Integer; external 'PASNETA.COM';
function setattr(var Func, Attribute: Integer; var Filename: Strvar): Integer; external xtndopn[3];
function eojstat(var Flag: Integer):integer; external xtndopn[6];
function PRLH_Log(var FileHandle,HiByteOffset,LoByteOffset,HiLockLen,
LoLockLen,Flags,TimeOut: Integer): Integer; external xtndopn[9];
function PRLH_Rel(var FileHandle,HiByteOffset,LoByteOffset,HiLockLen,
LoLockLen: Integer): Integer; external xtndopn[12];
function PRLH_Clr(var FileHandle,HiByteOffset,LoByteOffset,HiLockLen,
LoLockLen: Integer): Integer; external xtndopn[15];
function PRLF_Log(var fcb,HiByteOffset,LoByteOffset,HiLockLen,LoLockLen,
Flags,TimeOut: Integer): Integer; external xtndopn[18];
function PRLF_Rel(var fcb,HiByteOffset,LoByteOffset: Integer): Integer; external xtndopn[21];
function PRLF_Clr(var fcb,HiByteOffset,LoByteOffset: Integer): Integer; external xtndopn[24];
function PRLS_Lck(var Flags,TimeOut: Integer): Integer; external xtndopn[27];
function PRLS_Rel: Integer; external xtndopn[30];
function PRLS_Clr: Integer; external xtndopn[33];
function OpenSem(var Sema4: Strvar; var SemaValu,HiHandle,LoHandle,OpenCnt: Integer): Integer; external xtndopn[36];
function ExamSem(var HiHandle,LoHandle,SemaValu,OpenCnt: Integer): Integer; external xtndopn[39];
function WaitSem(var HiHandle,LoHandle,TimeOut: Integer): Integer; external xtndopn[42];
function SigSem(var HiHandle,LoHandle: Integer): Integer; external xtndopn[45];
function ClosSem(var HiHandle,LoHandle: Integer): Integer; external xtndopn[48];
[SNIP]
It's all very well the BT router (maybe) pumping out more power, but wifi comms is a two-way thing and your tablet or phone etc. is going to be transmitting at the same strength it has always done....so if the device's signal couldn't make it back from the potting shed before it STILL aint gonna make it back now.
The vouchers...don't forget the coloured vouchers...orange ones, green ones and...wow I bought enough to get a white and blue one!
Bless Doug Simmons...we had an electronics club stand at our school summer fair (about 1978/9) and I wrote to him for some marketing freebies and he sent a large box of catalogues and starship posters.
/Also 4 digits.
I'll just leave this here:
https://i.imgur.com/eTgF48e.jpg
"The Acorn System 1 is a grandparent of the BBC micro:bit; it was designed by Sophie Wilson and Steve Furber, who went on to help develop the BBC Microcomputer.
Acorn System 1:
Launched: 1979
Processor: 8-bit 6502, 1MHz
Approx MIPS: 0.5
RAM: 1.125kB
ROM: 512 bytes
BBC micro:bit:
Launched: 2016
Processor: 32-bit ARM Cortex M0, 16MHz
Approx MIPS: 13
RAM: 16kB
Flash: 256kB "
Help make the community happen - there's an Area 51 initiative on Stack Exchange to create a micro:bit Q&A site - please head over and upvote some of the questions that have not made it to 10 yet.
http://area51.stackexchange.com/proposals/96237/microbit
** Please don't upvote any question that already has 10 upvotes; they have already passed the needed score so it will be a wasted vote. **
Also check out this sub on Reddit: https://www.reddit.com/r/Micro_Bit/
(There's a couple of other micro:bit subs on Reddit, but that one is the most active)
Agreed, the ultimate launch date was not good and has meant the micro:bits being delivered so close to the end of the school year that there was little point in bringing them into the curriculum.
I am a STEM ambassador and we have a growing network of members who are tooled up with micro:bits and able to support schools who wish to use the board in conjunction with curriculum activities. You should encourage your school to reach out to the STEM organisation to see who could help either directly or remotely.
http://www.stemnet.org.uk/
I understand there was some talk about speccing the micro:bit with a larger RAM, but this would have meant moving to the next model of Nordic SoCs and the cost was considered too high.
The board is intended for basic coding and for that it's fine - if you require more RAM, then the micro:bit is probably not the right fit for your project.
The Zero has no LED matrix display, no bluetooth, no accelerometer, no built-in switches and no magnetometer so it's hardly ready 'out of the box' to do anything, plus prepping one for use can be a bit of hassle. The micro:bit can almost hit the ground running; I have both and the micro:bit is the best fit for its intended purpose.The Zero could be step 2 on a coding journey unless one moves to the Arduino ecosystem or somethig like the ST Nucleo boards.
> Of course not: all in-house IT systems have their DR plans fully documented, with a test failover performed monthly.
Actually we did a failover every two months on our in house system.
Yes, in-house IT can be a mess in many cases, but for any organisation with mission-critical parts kept in-house, *you* retain control of the specification and management of your live and redundant resources and can plan for business continuity and failover under your control and to a budget and resource pool that meets your requirements; perhaps even considering worse-case scenarios like hiring a shipping container data centre or, as in our case, being able to cannibalise other, less critical services, for parts while we wait for spares and an engineer to turn up within their 1/2/4/whatever hour response window.
As an example, we specced a standby system running a single unit tape backup/restore function (in case our autochanger failed) to have the same hardware as one of our primary servers. One day, the HP SAS caching controller on a live server failed and brought down the ERP system . While we were on the phone arranging a service call-out, another team member replaced the controller with the one from the 'spare' system. Total downtime was 12 minutes - and that was our only service break on that system in about 3 years.
When you rely on DR in a SAAS cloud-based environment, you won't likely have a dedicated engineer thinking about what they can do for you and your service - they will be taking a holistic view across the entire failed infrastructure and the solution will most likely take longer to implement unless its something simple like failed switch or router because whole systems/backups (ha - if they exist) will be being restored rather than just *your* systems and backups.
So...longer than an 8 hour wait at SFO before your flight to LHR is finally cancelled and you have to fly to Dulles and eventually arrive back home over one day late...and no you can't use our lounge while we dick around trying to work out how to get you home?
I refuse to fly United now .. all subsequent business flights have been with Virgin Atlantic.
/bitter? Much!
Important notes:
This is not an HDS system; it's from HGST - totally different organisations.
These systems use Erasure Coding to scatter elements of the stored objects across multiple disks (or sites, if you have more than one system), and rebuild times are based on the time taken to reconstruct the elements stored on one disk.
There are boxes out in the field (previous generation ones) for which reliability data is available, plus there are the ones in the labs and development centres. Overall, it's possible to calculate reliability figures based on the MTBF/AFR and other parameters for individual components.
Exactly! The storage policies which determine how objects are stored, how many parts they are spread across on the disks and how many parts we can afford to lose (the 'safety') is customer configurable and determines the effective storage size.
/Currently sitting in a training course at HGST for this, so getting a kick etc...
It was the mid/late 1980s and we'd just installed a row of spanking-new IBM PC-AT computers (286 processor, no less) running a CAD application called Daisy on a *nix OS called Daisy-DNIX. In those days RAM was very expensive so not a lot was fitted and the systems swapped to disk constantly.
Everything was going swimmingly until some electronic-engineer-who-should-have-known-better fancied a brew-up and plugged his electric kettle into the end socket on a run of daisy-chained (heh!) extension leads. Of course, the fuse blew in the FIRST plug and all the computers went down.
The resulting mess caused by machines that were shut down incorrectly while busily swapping took a couple of days to sort out.
Those machines swapped so much that we were forever replacing busted disks.
Happy days. Have a read: https://en.wikipedia.org/wiki/Daisy_Systems