Internally there is nothing rigid to crack, they should bend with enough force. Catching fire is a real concern, but if you can get the battery voltage down real low they should be inert enough to pry out if you can manage it without puncturing the pack. (you'd have to bypass whatever internal low voltage protections they have)
Yes. I'm glad there was no glue. Battery was swollen for at least a year until I replaced it. I remember there were three screes holding it in place so there was no glue by design. Wish current macbooks would hold up to this kind of serviceability.
me too, I think I spent 2 hours on the replacement just to get the old battery loose from all the glue, afraid I'd puncture it in the process. So. Much. Glue.
Perhaps the point of failure is not located inside the mechanics at all. I could imagine that dust is not necessarily always 100% non-conductive and might have an impact on pcb traces if their routing is very close (sporadic shortening).
Another interesting test would be heating up those microchips and see if potentially lose pins might be reflowed by this procedure.
curious if existing hardware can be upgraded later. i guess technically it might be feasable but vendors will try to make money and sell new hardware anyway. hoping for open router firmwares...
That would probably be radio firmwares; open router firmware isn't rare (openwrt, dd-wrt, tomato, etc.). And yes, it would be nice to get open radio firmware, though I'm not sure how that would play with FCC certification? I suppose if enough stuff is regulated in hardware it could work.
It requires stronger encryption but assuming your hardware is up to the task it'll work. If you're using OpenWRT recent builds with an up to date hostapd support it.
I use it on Mac every day. The regi client is not required on the Mac version and it works just fine. I don't understand how you can make claims without even trying
Are you sure you are able to upload code to a running instance deployed on an amazon AMI, right from the IDE running on your mac ?
I even asked someone from SAP and had a look at various forums on the sap dev network. Everyone seemed to agree that Windows was the way to go (the SAP guy even advised me to install a Windows VM). Glad to hear i was wrong.
I am sure. Disclaimer: I work for SAP and I am the one who originally created those amazon AMIs about two years ago. Meanwhile I got re-org'd into some other group (as happens frequently at big companies) but I still use it myself. I'll clarify things on our forums (not that anyone would find it there...)
Lol ! ok, HN really is something wonderful :) Well, the first step to me is in the download page : explain a bit more what those "client" downloads are and when and why they are required.
PS : don't know if you're still involved with SAP Hana, but that technology would really benefit from having its completely independent ecosystem, far from anything related to SAP and its bloated developer network & forum website.
The "Client" is database drivers for different environments. JDBC, OCBC, ODBO, Python. Unfortunately, drivers only exist for Windows and Linux - but the JDBC driver is pure Java, so if you want to code Java against HANA from a Mac, you can do it (simply download any Client package, unzip and use the jgdbc.jar as JDBC driver.
The best choice is not even in the package: node.js drivers for HANA. Easiest way to get is
npm install hdb
Full (!) Open Source, https://github.com/SAP/node-hdb
Fully agree with your comment about independent ecosystem. I'm not officially related anymore, but still pushing internally.
HANA (even HANA One) is too expensive, there's not obvious go-to-market route for smaller shops and all that information is purely curated hence hard to navigate. Well, SAP is just beginning to open up, so call it beginners mistakes. And hope we'll learn fast...
We can do DSSS, but our radio engineer (google Earl McCune) advised us that FHSS, while in some ways more complex (actually he just said it's tricker to design "right", which I'm fine with), will be vastly better for rejecting interference and intentional blocking.
Thanks! He's a serious silicon valley radio expert. He actually was a member of the homebrew computer club and brushed shoulders with Woz and Jobs before spending the rest of his career advancing radio in silicon valley. He helped lab test my designs, and he's really been an asset in verifying that what I think I did right, I actually did (Texas Instruments has some really great reference material). We experimentally verified on his equipment that my design basically exactly matches the performance characteristics of TI's reference design, and one of our RF component suppliers offers a $600 service where they put your device in their RF chamber to test emissions, which the engineer told me is a much better deal than you'd normally get at that price, but they only do it to help customers get off the ground. Before launch we spent a lot of time speaking to a lot of other professionals and kickstarter folk who have gone through the certification process, and it sounds like it's going to be manageable, especially with Earl McCune's help! I've done all the work on my own, but having a reliable expert is extremely critical in making sure the hardware will not be a problem!
Reddit is certainly not a design with simplicity in mind. The sheer amount of links and navigation in general is completely overwhelming. I'd say it's rather a poor design.
