|
all communities have redundant poo poo out the rear end opensource is just more obvious because everyone can see it timing events over the web i can't wait for lag in every aspect of my life what if my toilet times out while trying to flush
|
#
?
Aug 15, 2013 00:54
|
|
|
|
| # ? Jun 12, 2024 06:25 |
|
|
abraham linksys posted:i think we can all agree that lowering the barrier to entry for embedded development is a Good Thing) Greenglow, a javascript framework for operating nuclear facilities,
|
|
#
?
Aug 15, 2013 01:01
|
|
|
coffeetable posted:Greenglow, a javascript framework for operating nuclear facilities, lol Coffinscript, a javascript framework for medical devices.
|
|
#
?
Aug 15, 2013 01:10
|
|
|
Cocoa Crispies posted:
Ended up making one. Your distributed system advocates a way to beat the CAP theorem. Your idea will not work. Here is why it won't work: (x) you're actually building an AP system ( ) you're actually building a CP system ( ) you are not, in fact, designing a distributed system (x) you pushed the actual problem to another layer of the system (x) you are assuming that network/hardware failures will not happen ( ) your solution is equivalent to an existing one that doesn't beat CAP Specifically, your plan fails to account for: ( ) latency is a thing that exists ( ) high latency is indistinguishable from splits or unavailability ( ) a split node cannot be differentiated from a crashed one ( ) stable storage may become corrupt ( ) there might be more than 1 partition at the same time ( ) network topology changes over time (x) clients are also part of the distributed system ( ) deleted items will come back after synchronization with other nodes ( ) clocks drift across multiple parts of the system, forward and backwards in time ( ) network failures will actually happen ( ) hardware failures will actually happen ( ) operator errors will actually happen (x) side effects cannot be rolled back the way transactions can ( ) failures can occur while in a critical part of your algorithm ( ) split nodes can vanish forever (x) things can happen at the same time on different machines (x) designing distributed systems is actually hard And the following technical objections may apply: ( ) using 'infinite timeouts' is not an acceptable solution to lost messages ( ) your quorum size cannot be changed over time ( ) your system accumulates data forever and assumes infinite storage (x) re-synchronizing data will require more bandwidth than everything else put together ( ) acknowledging reception is not the same as confirming consumption of messages ( ) your solution requires a central authority that cannot be unavailable (x) you assume short periods of unavailability are insignificant ( ) read-only mode is still unavailability for writes (x) you are basing yourself on a paper or theory that has not yet been proven Furthermore, this is what I think about you: (x) you have no idea what you are doing ( ) you are badly reinventing existing concepts and should do some research (x) you shouldn't be in charge of people's data ( ) nice try, but blatantly false advertising (x) you should read the definition of the word 'theorem' ( ) you should read the definition of 'distributed system' MononcQc fucked around with this message at 02:14 on Aug 15, 2013 |
|
#
?
Aug 15, 2013 01:40
|
|
|
|
|
#
?
Aug 15, 2013 01:51
|
|
|
MononcQc posted:Ended up making one. aww yiss.
|
|
#
?
Aug 15, 2013 10:10
|
|
|
http://secretvolcanobase.org/~tef/distributed_system.txt made a few edits.
|
|
#
?
Aug 15, 2013 10:25
|
|
|
cool now someone make one of these with ruby tia
|
|
#
?
Aug 15, 2013 10:31
|
|
|
coffeetable posted:Greenglow, a javascript framework for operating nuclear facilities, 
|
|
#
?
Aug 15, 2013 12:55
|
|
|
woops i confused a software core dump with an actual nuclear core dump! silly type juggling!
|
|
#
?
Aug 15, 2013 13:29
|
|
|
tef posted:http://secretvolcanobase.org/~tef/distributed_system.txt made a few edits. you have a secret volcano base too?
|
|
#
?
Aug 15, 2013 13:38
|
|
|
who doesn’t ? ps http://ferd.ca/beating-the-cap-theorem-checklist.html 
|
|
#
?
Aug 15, 2013 13:56
|
|
|
can you crosspost that on programmingisterrible with a subtle link to tacodb somewhere tia
|
|
#
?
Aug 15, 2013 14:06
|
|
|
congrats monocqc youre #4 on hn
|
|
#
?
Aug 15, 2013 15:15
|
|
|
gucci void main posted:congrats monocqc youre #4 on hn thanks for the hn update, how's the job going?
|
|
#
?
Aug 15, 2013 15:18
|
|
|
Cocoa Crispies posted:thanks for the hn update, how's the job going? great ty for asking.
|
|
#
?
Aug 15, 2013 15:22
|
|
|
abraham linksys posted:nah it's not nearly that cool, it just comes with a JS API for developing on it. think of it like arduino's java APIs No. No it is not a good thing. real embedded development tends to involve carefully managing your resources, because if you're using an embedded system odds are you want to use as little of everything as possible - as little power, as little memory, as little storage, as few instructions when i think of javascript, i think of none of those things but yeah the world definitely needs another batch of arduino led blinkers who are totally definitely real embedded developers
|
|
#
?
Aug 15, 2013 16:49
|
|
|
Bloody posted:but yeah the world definitely needs another batch of arduino led blinkers who are totally definitely real embedded developers arduino led blinkers who couldn't hack it in arduino c so they need jquery
|
|
#
?
Aug 15, 2013 16:52
|
|
|
Bloody posted:No. No it is not a good thing. real embedded development tends to involve carefully managing your resources, because if you're using an embedded system odds are you want to use as little of everything as possible - as little power, as little memory, as little storage, as few instructions i too think that all forms of development should be gated communities with no easy entry point
|
|
#
?
Aug 15, 2013 16:53
|
|
|
$('blinkers').onblink(function(state) { ... })
|
|
#
?
Aug 15, 2013 16:54
|
|
|
yeah because embedded c is so loving difficult
|
|
#
?
Aug 15, 2013 16:54
|
|
|
Bloody posted:yeah because embedded c is so loving difficult it's definitely more difficult than most of the stuff people use to get started in programming
|
|
#
?
Aug 15, 2013 16:56
|
|
|
then again my idea of embedded is more like "msp430" not like "arm" lol do people actually consider arm things to be embedded?
|
|
#
?
Aug 15, 2013 16:56
|
|
|
Looks forward to GC pauses in my toaster.
|
|
#
?
Aug 15, 2013 16:57
|
|
|
abraham linksys posted:i too think that all forms of development should be gated communities with no easy entry point learning C is the easy entry point embedded dev before inexpensive ways to do C was the hellish nightmare
|
|
#
?
Aug 15, 2013 16:57
|
|
|
Development should have barriers to entry. Much like regular engineering does.
|
|
#
?
Aug 15, 2013 16:58
|
|
|
prefect posted:it's definitely more difficult than most of the stuff people use to get started in programming i don't believe you. syntactically it's ~as complex as common starters (every real language uses c-style syntax) and blinking LEDs in a memory-mapped environment is probably the simplest program that can exist. changing the language doesn't get you away from having to deal with embedded concepts like registers and memory-mapped i/o unless you're just doing it to bury everything in libraries which guess what you can do in c as well.
|
|
#
?
Aug 15, 2013 16:58
|
|
|
Bloody posted:i don't believe you. syntactically it's ~as complex as common starters (every real language uses c-style syntax) and blinking LEDs in a memory-mapped environment is probably the simplest program that can exist. changing the language doesn't get you away from having to deal with embedded concepts like registers and memory-mapped i/o unless you're just doing it to bury everything in libraries which guess what you can do in c as well. i should probably have kept my piehole shut; i've never done embedded development (or c development) (or any Serious Software Product Development, even) 
|
|
#
?
Aug 15, 2013 17:01
|
|
|
the blinkinglights program is difficult in that your typical high-level language coder has to be repeatedly whacked with a board that say "no the computer doesn't inherently provide X" until it is finally understood
|
|
#
?
Aug 15, 2013 17:14
|
|
|
but javascript is perfect when you want to code close to the metal 
|
|
#
?
Aug 15, 2013 17:16
|
|
|
js is pretty fast - faster than ruby, for sure - but i guess the issue is one of memory consumption, not actual run speed
|
|
#
?
Aug 15, 2013 17:18
|
|
|
the only reason JS is not running on embedded platforms yet is that electrical engineers and the people usually working in embedded nevironment haven't embraced the DOM model yet!
|
|
#
?
Aug 15, 2013 17:24
|
|
|
what do you mean I can't map canvas elements over the LEDs
|
|
#
?
Aug 15, 2013 17:24
|
|
|
"simple" ≠ "easy" hth
|
|
#
?
Aug 15, 2013 17:28
|
|
|
my embedded experience is pretty limited, but i don't think that hiding the constraints of your system is the best way to educate new devs. if you're used to practically unlimited resources and take that mindset over to embedded systems then idk. on the other hand, if they expose lower level functionality through their APIs and encourage users to understand the underlying hardware then that might be cool. don't know how that would even work though.
|
|
#
?
Aug 15, 2013 17:35
|
|
|
god drat, they just removed the <blink> tag, that would have made this project so much easier, gently caress
|
|
#
?
Aug 15, 2013 17:35
|
|
|
Bloody posted:then again my idea of embedded is more like "msp430" not like "arm" launchpad makes msp430 pretty easy idk how you do anything more complicated than blinkenlights without knowing how interrupts and stuff work
|
|
#
?
Aug 15, 2013 18:35
|
|
|
QPZIL posted:the poo poo does this even mean it is a difficult question because its meaning is impossible to describe. one might ask the same about databases: What is a database, really? we just don't know
|
|
#
?
Aug 15, 2013 18:56
|
|
|
a desconstructionist, post modern look at databases
|
|
#
?
Aug 15, 2013 19:06
|
|
|
|
| # ? Jun 12, 2024 06:25 |
|
|
Zombywuf posted:Development should have barriers to entry. Much like regular engineering does. nope engineering has barriers to entry because people would die if it didn't. a badly coded website isn't going to start a house fire. if you don't want to maintain awful code, raise barriers to employment in your workplace, but don't raise barriers to entry.
|
|
#
?
Aug 15, 2013 19:15
|
|