Very much so. It's supported by all providers who are not just a bunch of Cisco boxes in a closet, it has better tolerance of latency and does not break with any form of NAT.
It's not commonly supported by phones but it works great between gateways/switches.
That means you're frequently banned knowledge/access that would be extremely useful to your job, because an external entity wouldn't have that knowledge.
Solution: open that knowledge for competitors. Regulations are not created to favor your profits over theirs.
It gets even more ridiculous if you're working for two different departments at the same time, because often it means for two related projects you have to develop one pretending you have zero knowledge of the other.
Solution: don't have convoluted and probably semi-fraudulent system of departments that allows one person to be employed by multiple ones.
link status will have to be propagated through the neighbors - false. for instance, they can use an acknowledge protocol to passively learn link status
What does it mean?
Either everyone is asking me how much I can pass (creating enough traffic that I can't pass anything at all), or I report it to someone, and they distribute it through the network or use only for their local part of the routing mechanism (and then they don't really care where I am physically).
but then geometry will be utterly irrelevant - false - geometry - do you mean topology or geolocation?
Physical distance determined by GPS. What should not be necessary if link parameters and network topology are already known -- if you can hear me over RF, you may be interested in my link, otherwise existence of my link only matters as a part of aggregated data that predicts available bandwidth when you route through my neighbors.
My example with a phone in Oakland demonstrates a situation when there is one obvious route for almost everyone, and it's the wrong one for the vast majority of those who thinks that it may be optimal.
But they will still contact me first, DoSing my phone by routing requests alone! To avoid that, link status will have to be propagated through the neighbors, but then geometry will be utterly irrelevant.
Gas fills up the whole container, however pressure on top and bottom parts of the container will still show the difference produced by gravity, so total force the gas applies to the container is directed down, and equal to the mass of gas multiplied by free fall acceleration (well, an integral over the volume of gas if we have uneven gravity, however on Earth surface it's negligible).
Well, Visual Studio can have two (or three, or four) windows side-by-side showing different parts of the source. It has good multi-monitor support and isn't written in Java.
Anf it still has myriad of parasite windows, tied to Microsoft toolchain that is worthless for embedded systems, and we should expect next version to be touchscreen-based or something similarly idiotic. No, thanks.
Code completion is a really nice feature that only IDEs offer.
If you need code completion, then either you are retarded, your environment is retarded, or both.
A text editor that doesn't constantly guess what you are trying to fat-finger can't give you very much help in that regard.
FTFY.
Even basic stuff like being able to right click on something and see all references to it and jump directly to the definition is a huge improvement over hunting through files in a text editor.
In a sane project, a second window is a much better way of looking at referred code. You should never try to look for referring code, because it should never matter in a proper design except when you are changing the interface -- and then no GUI will help you.
If you have to constantly look at definitions, you have inconsistent interface in your product, and you should not use it in the first place. Except when it's Windows, but embedded systems developers already fixed that little problem.
Visual Studio isn't what you would call "light weight", but it does a lot for you that is really, really worth having. Not in a hold-your-hand my-first-program way, but in an experienced-engineer-with-a-large-complex-project-to-work-with way.
Every shit programmer says that. The truth is, Visual Studio is designed for developers Microsoft wants to have -- dumb and churning out loads of tightkly coupled spaghetti code.
And yes, Atmel Studio will still let you use a makefile and command line compilation if you really want to.
So will Emacs, but it won't impose retarded internal "tools" on the programmer.
Indeed, would that it were so. Unfortunately, someday, you'll graduate from college and you'll have to work in the real world, where you will find lousy code written by vendors, other teams, or (hopefully) former members of the team.
I have graduated from university in 1993, and in 20 years I have found nothing to contradict my position on this. An asshole who writes buggy code and applies software development practice equivalent of bogosort, is in no position to adopt such a condescending tone while talking to me.
At worst, I may benefit from cross-referencing, but it does not have to be welded into the guts of my editor, and insist on creating myriad of little windows, so I can't have my favorite layout -- two editor windows side by side, one where I edit code, one where I refer to things, and a terminal window with shell, where I run compilation, target loader, manual, searches, version control, etc.
IDE will fill the whole screen with its decoration-heavy MDI, stuff file window there, symbol window here, allocate three lines at the bottom for console, add six lines of status, tabs and toolbars around it... On a widescreen monitor I end up seeing less of the source code than I did on 1024x768 CRT, and any attempt to close those parasite window break some functionality. Thanks no.
And that's bad. Good code must be readable on its own. If I need a reverse-engineering environment, it should better be not for things that I, or people on my project, write.
Good IDEs have ways to search across symbols, source files, etc. They allow you to quickly search for references to symbols. They allow integration of one-click compiler-error/warning-to-source jumps.
So does Emacs.
They do static analysis and performance profiling.
No, they don't.
They have easy ways of pausing execution modifying code and resuming execution.
On an embedded system you should not be able to do that at all.
They let you use version control from inside them.
What for?
They have plug-in oriented debuggers that let you write simple visualizations for your own datastructures and much much more.
The less a programmer touches a debugger, the less bugs are in the code.
All of those things save development time.
Those features are training wheels and crutches. If you can benefit from them, you are not supposed to work on the project in the first place.
Thankfully the vast majority of programmers these days have a choice for using an IDE.
The vast majority of programmers these days have negative performance outcome -- more time is spent by others fixing their mistakes than would be spent working without them.
Nobody sane would want to maintain Makefiles, unless it was the only option.
If it's difficult for you to add a source file to a Makefile, it's impossible for you to write that file.
Your opinion of people who use IDEs is outdated propaganda.
Not of people who use IDEs -- people who NEED IDEs.
avrstudio is pretty good for embedded avr, or gcc+avrdude.
And just regular gcc, avr-libc and avrdude is still better without any shitty environment on top. With whatever editor you prefer.
Really, what is this obsession with integrated development environments, with their crappy UI, editors that can't let me have two windows with different parts of a source file side by side, implemented in Java or worse, and with no redeeming qualities other than letting a user to mash one button to start the build? Do people really expect that much handholding while doing very complex kind of software development, dealing with hardware, interrupts, concurrency, etc. in the minimal environment, but they cant write a makefile? What kind of bugs do they write, ones that cause them to endlessly compile and recompile code, making random changes until something seems to work? Really? That's their workflow?
Screw that. Learn to use command line, and don't recompile every second. Use your head.
Slashdot Mirror
I call bullshit on that.
It's a toll bridge, not a troll bridge.
fines of up to $1.7 million
or all change in the CEO's pocket, whatever is greater?
If you perform work on an object, it must perform work back to give your measuring device something to read. Action-equal-opposite-reaction.
This is the depth of ignorance that I have not seen in years. And I live in US.
Very much so. It's supported by all providers who are not just a bunch of Cisco boxes in a closet, it has better tolerance of latency and does not break with any form of NAT.
It's not commonly supported by phones but it works great between gateways/switches.
Under the yolk of Artificially Scarce Ideas, no less.
That means you're frequently banned knowledge/access that would be extremely useful to your job, because an external entity wouldn't have that knowledge.
Solution: open that knowledge for competitors. Regulations are not created to favor your profits over theirs.
It gets even more ridiculous if you're working for two different departments at the same time, because often it means for two related projects you have to develop one pretending you have zero knowledge of the other.
Solution: don't have convoluted and probably semi-fraudulent system of departments that allows one person to be employed by multiple ones.
i guess everyone developing web apps probably uses 2 screens nowadays.
Maybe. When I had to do that, it was three screens -- editor, non-IE browser, IE6. Because IE6 is special.
link status will have to be propagated through the neighbors - false. for instance, they can use an acknowledge protocol to passively learn link status
What does it mean?
Either everyone is asking me how much I can pass (creating enough traffic that I can't pass anything at all), or I report it to someone, and they distribute it through the network or use only for their local part of the routing mechanism (and then they don't really care where I am physically).
but then geometry will be utterly irrelevant - false - geometry - do you mean topology or geolocation?
Physical distance determined by GPS. What should not be necessary if link parameters and network topology are already known -- if you can hear me over RF, you may be interested in my link, otherwise existence of my link only matters as a part of aggregated data that predicts available bandwidth when you route through my neighbors.
My example with a phone in Oakland demonstrates a situation when there is one obvious route for almost everyone, and it's the wrong one for the vast majority of those who thinks that it may be optimal.
Windows RT users
Who?
They weren't stupid enough to release Windows for desktop with tablet-oriented UI, and now they are, and they did.
But they will still contact me first, DoSing my phone by routing requests alone!
To avoid that, link status will have to be propagated through the neighbors, but then geometry will be utterly irrelevant.
So if I'll stand in Oakland with a phone, and there is Macworld in San Francisco, then almost every iPhone in US will route video stream through me?
Gas fills up the whole container, however pressure on top and bottom parts of the container will still show the difference produced by gravity, so total force the gas applies to the container is directed down, and equal to the mass of gas multiplied by free fall acceleration (well, an integral over the volume of gas if we have uneven gravity, however on Earth surface it's negligible).
You're right - I should have included a sarcasm tag.
No, you should have included false analogy tag.
Just like how cellphones will never fit into your pocket.
Congratulations, you are an idiot!
Well, Visual Studio can have two (or three, or four) windows side-by-side showing different parts of the source. It has good multi-monitor support and isn't written in Java.
Anf it still has myriad of parasite windows, tied to Microsoft toolchain that is worthless for embedded systems, and we should expect next version to be touchscreen-based or something similarly idiotic. No, thanks.
Code completion is a really nice feature that only IDEs offer.
If you need code completion, then either you are retarded, your environment is retarded, or both.
A text editor that doesn't constantly guess what you are trying to fat-finger can't give you very much help in that regard.
FTFY.
Even basic stuff like being able to right click on something and see all references to it and jump directly to the definition is a huge improvement over hunting through files in a text editor.
In a sane project, a second window is a much better way of looking at referred code. You should never try to look for referring code, because it should never matter in a proper design except when you are changing the interface -- and then no GUI will help you.
If you have to constantly look at definitions, you have inconsistent interface in your product, and you should not use it in the first place. Except when it's Windows, but embedded systems developers already fixed that little problem.
Visual Studio isn't what you would call "light weight", but it does a lot for you that is really, really worth having. Not in a hold-your-hand my-first-program way, but in an experienced-engineer-with-a-large-complex-project-to-work-with way.
Every shit programmer says that. The truth is, Visual Studio is designed for developers Microsoft wants to have -- dumb and churning out loads of tightkly coupled spaghetti code.
And yes, Atmel Studio will still let you use a makefile and command line compilation if you really want to.
So will Emacs, but it won't impose retarded internal "tools" on the programmer.
Indeed, would that it were so. Unfortunately, someday, you'll graduate from college and you'll have to work in the real world, where you will find lousy code written by vendors, other teams, or (hopefully) former members of the team.
I have graduated from university in 1993, and in 20 years I have found nothing to contradict my position on this. An asshole who writes buggy code and applies software development practice equivalent of bogosort, is in no position to adopt such a condescending tone while talking to me.
At worst, I may benefit from cross-referencing, but it does not have to be welded into the guts of my editor, and insist on creating myriad of little windows, so I can't have my favorite layout -- two editor windows side by side, one where I edit code, one where I refer to things, and a terminal window with shell, where I run compilation, target loader, manual, searches, version control, etc.
IDE will fill the whole screen with its decoration-heavy MDI, stuff file window there, symbol window here, allocate three lines at the bottom for console, add six lines of status, tabs and toolbars around it... On a widescreen monitor I end up seeing less of the source code than I did on 1024x768 CRT, and any attempt to close those parasite window break some functionality. Thanks no.
A good IDE helps you read code.
And that's bad. Good code must be readable on its own. If I need a reverse-engineering environment, it should better be not for things that I, or people on my project, write.
Good IDEs have ways to search across symbols, source files, etc. They allow you to quickly search for references to symbols. They allow integration of one-click compiler-error/warning-to-source jumps.
So does Emacs.
They do static analysis and performance profiling.
No, they don't.
They have easy ways of pausing execution modifying code and resuming execution.
On an embedded system you should not be able to do that at all.
They let you use version control from inside them.
What for?
They have plug-in oriented debuggers that let you write simple visualizations for your own datastructures and much much more.
The less a programmer touches a debugger, the less bugs are in the code.
All of those things save development time.
Those features are training wheels and crutches. If you can benefit from them, you are not supposed to work on the project in the first place.
Thankfully the vast majority of programmers these days have a choice for using an IDE.
The vast majority of programmers these days have negative performance outcome -- more time is spent by others fixing their mistakes than would be spent working without them.
Nobody sane would want to maintain Makefiles, unless it was the only option.
If it's difficult for you to add a source file to a Makefile, it's impossible for you to write that file.
Your opinion of people who use IDEs is outdated propaganda.
Not of people who use IDEs -- people who NEED IDEs.
avrstudio is pretty good for embedded avr, or gcc+avrdude.
And just regular gcc, avr-libc and avrdude is still better without any shitty environment on top. With whatever editor you prefer.
Really, what is this obsession with integrated development environments, with their crappy UI, editors that can't let me have two windows with different parts of a source file side by side, implemented in Java or worse, and with no redeeming qualities other than letting a user to mash one button to start the build? Do people really expect that much handholding while doing very complex kind of software development, dealing with hardware, interrupts, concurrency, etc. in the minimal environment, but they cant write a makefile? What kind of bugs do they write, ones that cause them to endlessly compile and recompile code, making random changes until something seems to work? Really? That's their workflow?
Screw that. Learn to use command line, and don't recompile every second. Use your head.
This guy.
http://www.rpgmp3.com/downloads/data/av-deadalewives-dnd-part-1-stream.mp3
To attack the darkness.