HN user

gryph0n

24 karma
Posts0
Comments22
View on HN
No posts found.

As suggested, one path is to port Rockbox firmware for your MP3 player. However, since you do not have any prior experience in embedded domain, it will not be a easy path.

I would suggest that you try using the Arduino or RaspberryPI hardware. Both of these platforms are widely used, so you would be able to easily get help if you get stuck. Also, these are 'simple' platforms that are widely available, so the learning materials available is unmatched.

Building a simple project like a weather station or clock will keep you focused on a "actual" target/goal.

https://www.arduino.cc

https://create.arduino.cc/projecthub/projects/tags/clock

http://cactus.io/projects/weather/arduino-weather-station

https://www.raspberrypi.org

https://howchoo.com/pi/how-to-make-a-raspberry-pi-smart-alar...

https://projects.raspberrypi.org/en/projects/build-your-own-...

The sales model is pretty different.

In India, you'll typically buy your phone outright based on what features you're looking for (Dual SIM, OS version, Storage, etc). Hence manufacturers/retailers typically offer a EMI plan for top-end phones (think Samsung S7, Apple iPhone 6, etc) since the outright cost is quite high.

Then you'll decide which carrier you want to use based on the tariffs they're offering (Voice Calls, data, SMS, etc.)

Although carriers do offer phones with their plans, it's rarely ever bought in that manner.

I don't think Borland's mismanagement was a strong factor in C/C++ gaining mindshare.

The native OS interfaces on popular platforms (Win32, Posix) were in C, so it would have always been a 2nd class citizen.

I believe that Delphi was already on a decline when Borland decided to self destruct.

On Win32, they had a tough time competing after VisualBasic v5.0, where Microsoft had a larger mind-share.

On Linux, I had hopes with the Kylix port, but it was abandoned by Borland.

https://en.wikipedia.org/wiki/Kylix_(software)

>something that's unheard of in India.

Maybe not if you're in the 'upper middle class'. If you're from the lower income classes (maids, drivers, helpers), it's very likely that health issues can bankrupt you.

I personally know an entire family that has sunk into debt that they couldn't possibly pay-off, due to health related expenses for someone in the family.

As an un-involved observer, what I see is that PA/Hamas would rather focus on fighting Israel than making life better for their residents. They would much rather receive un-accountable funds to line their own pockets than do anything constructive.

Israel (or rather individual Israelis), on the other hand, seems to have a significant focus on improving quality of life for themselves.

Forget the Posix/Win32 platforms, function pointers can be easily found in the Standard C library itself. I believe there are atleast 2 functions taking function pointers as parameters:

1.>'qsort' function takes a function pointer to decide how to compare your data in order to sort it, presumably using quick sort.

2.>'signal' function has a Posix origin, but it did manage to make it into the C standard. It takes a function pointer to decide which function to call on getting a particular signal.

write() is an OS system call, while printf() is a C function call.

C libraries can (and do) choose to buffer printf, while read/write are usually unbuffered.

Of course, both are mechanisms are modifying some global state (your terminal's state), and cannot be relied to be free of race-conditions.

I second that. I'm so used to VI that I literally felt like a fish out of water when editing code with 'vanilla' Visual Studio. VsVim has saved my butt; I'd be lost without VsVim.

Now, with VsVim, I get the best of both worlds: IDE functionalities like refactoring, and excellent code completion, and the familiar VI key-bindings to edit the code.

If you're a heavy browser user, or if you simply never close your browser, you'll frequently run into the scenario where 32 bit Firefox reaches the 2GB virtual memory limit, whereupon it gets killed. Yep, it's 2GB, atleast on 32bit OS (I'm on Win 7 32bit).

Just the convenience factor of not having to restart my browser frequently is enough to make me want to embrace x64. My blocker is that my corporate IT policy is to have 32 bit OS.

I run into the 2G limit very frequently too. I usually shutdown my home & work systems only once a week. Firefox too runs continuously from the 1st day of the week.

Over the duration of a week, as I open more webpages, the virtual memory consumption rises continuously till it hits the 2G limit and then the process kills itself. Usually during the last few hundred MB before the 2G limit, it becomes pretty unresponsive.

I believe you're referring to the linker options for large memory awareness http://msdn.microsoft.com/en-us/library/wz223b1z%28v=vs.80%2...

I'd be glad if as a user (not developer) I can set that option somewhere.

P.S., I am a developer, but over time, you learn that building unfamiliar codebases is not a trivial exercise. On Win32, I'm just happier downloading vendor provided binaries. On Linux, I can be both, happy and frustrated, building my own binaries with Gentoo.

Yes, the PalmOS UI was very good. I think the Palm team really asked themselves 'What would be a good interface for a handheld device?'

In contrast, their competition at that time was Microsoft PocketPC. MS just had a terrible UI. It looked like they had shoe-horned the desktop UI onto a tiny device. I mean, 'Start' button on a handheld device ??

It might have been comforting to 'enterprise' customers to have a familiar interface, but it just sucked compared to the elegant PalmOS UI which looked like it had been designed for a tiny screen.

I was doing development with PalmOS around 2003-2004 timeframe, and the SDK had tools I have yet to see in other platforms to date.

'Gremlins': Automated fuzz testing within the emulator. Still waiting to see this make an appearance in other SDKs

'Debug ROMS': I've seen some SDKs including debug ROMs, but the ones on the PalmOS were actually useful. The ROMs would actually tell you what functions needed to be invoked before the current one (PalmOS needed memory pointers to be locked before any writing/copying operations could be allowed)

Agree with you on the memory starvations. We were porting another application from Symbian, and we had to jump through many hoops because the default code segment was limited to 64k.