thảo luận [Tâm sự] Nghề dev Linux kernel ở Việt Nam

Mình làm embedded linux - lớp app. Cái gì visible với user mới là selling point thôi. Kernel không phải cái user nhìn thấy và đặc thù của nó nên không phải cty nào của US/EU cũng đầu tư vào nguồn lực linux kernel - kể cả công ty rất to nhé - không phải là vì họ ko có tiền mà vấn đề là lượng công việc về kernel không nhiều - tuyển mấy bạn kernel expert về mà không có việc giao cho họ thì họ cũng sẽ ra đi thôi. Công việc liên quan đến kernel thường sẽ nhiều ở phase bringup board (thường ở EVB hoặc EVT) - nên việc nhiều trừ khi công ty có rất nhiều sản phẩm hw products được phát triển hàng năm (cái này không phải nhiều công ty) - đó là lý do phần hw design + bsp được outsource cho các cty design house ở Taiwan hoặc Trung Quốc nhiều - và các công ty focus vào application - phần core value của họ. Thường mình chọn SOC của hãng nào thì hãng đã có BSP riêng cho SOC, có vấn đề gì thì có thể get support từ hãng. Tất nhiên việc support này cũng có giới hạn - phụ thuộc vào volume của sản phẩm. Với các phân khúc mobile thì cỡ hàng chục triệu sản phẩm vẫn là nhỏ. Các công ty design house có mối quan hệ tốt với nhà cung cấp SOC - nên họ dễ get support hơn. Đó cũng là ưu điểm khi thuê các cty design house.
Nói như vậy không có nghĩa là phủ nhận việc cần hiểu linux kernel. Tuy nhiên linux kernel mình cũng không nghĩ nó khó đến nỗi không tiếp cận được. Nếu lập trình với MCU, RTOS rồi thì tiếp cận linux kernel cũng không khó. Bản chất vẫn là cần hiểu môi trường linux kernel code đang chạy trên đó. Các service mà linux kernel cung cấp không nhiều - quan trọng là hê sinh thái sống trong nó như USB subsystem, networking subsystem, audio/video subsystem,... Phần driver code mới là phần phức tạp nhất của linux kernel bởi nó dính tới đủ loại device khác nhau. Làm application mảng nào thì sẽ phải nắm rõ phần đó. Ví dụ:
  • Làm về interface thì sẽ cần hiểu hoạt động của các driver như GPIO, SPI, I2C,.. Đơn giản như để config pin thì sẽ cần hiểu về device tree, pinctrl/gpio system & device tree bindings, khai báo default pinctrl status...
  • Làm về battery control thì sẽ cần tìm hiểu việc điều khiển power system, config charger, pmic - nhiều khi sẽ cần sửa hoặc porting driver của mấy con charger/pmic này từ code base của mấy dòng tương dương.
Nên làm embedded linux system đủ lâu và đủ sâu thì rồi cũng sẽ phải động tới kernel code thôi.
Team nhỏ thì họ lựa chọn dùng các platform open, support tốt từ cộng động, google.
Team lớn và sản phẩm chuyên biệt thì bắt buộc sẽ phải customize lại - thì hoặc lựa chọn trả tiền thuê support hoặc phải tự giải quyết vấn đề.
Chia sẻ nhanh của mình thôi - hơi lan man có thể ko giống ý mà chủ topic muốn đề cập. :D.
 
nhimngoc said:
Mình làm embedded linux - lớp app. Cái gì visible với user mới là selling point thôi. Kernel không phải cái user nhìn thấy và đặc thù của nó nên không phải cty nào của US/EU cũng đầu tư vào nguồn lực linux kernel - kể cả công ty rất to nhé - không phải là vì họ ko có tiền mà vấn đề là lượng công việc về kernel không nhiều - tuyển mấy bạn kernel expert về mà không có việc giao cho họ thì họ cũng sẽ ra đi thôi. Công việc liên quan đến kernel thường sẽ nhiều ở phase bringup board (thường ở EVB hoặc EVT) - nên việc nhiều trừ khi công ty có rất nhiều sản phẩm hw products được phát triển hàng năm (cái này không phải nhiều công ty) - đó là lý do phần hw design + bsp được outsource cho các cty design house ở Taiwan hoặc Trung Quốc nhiều - và các công ty focus vào application - phần core value của họ. Thường mình chọn SOC của hãng nào thì hãng đã có BSP riêng cho SOC, có vấn đề gì thì có thể get support từ hãng. Tất nhiên việc support này cũng có giới hạn - phụ thuộc vào volume của sản phẩm. Với các phân khúc mobile thì cỡ hàng chục triệu sản phẩm vẫn là nhỏ. Các công ty design house có mối quan hệ tốt với nhà cung cấp SOC - nên họ dễ get support hơn. Đó cũng là ưu điểm khi thuê các cty design house.
Nói như vậy không có nghĩa là phủ nhận việc cần hiểu linux kernel. Tuy nhiên linux kernel mình cũng không nghĩ nó khó đến nỗi không tiếp cận được. Nếu lập trình với MCU, RTOS rồi thì tiếp cận linux kernel cũng không khó. Bản chất vẫn là cần hiểu môi trường linux kernel code đang chạy trên đó. Các service mà linux kernel cung cấp không nhiều - quan trọng là hê sinh thái sống trong nó như USB subsystem, networking subsystem, audio/video subsystem,... Phần driver code mới là phần phức tạp nhất của linux kernel bởi nó dính tới đủ loại device khác nhau. Làm application mảng nào thì sẽ phải nắm rõ phần đó. Ví dụ:
  • Làm về interface thì sẽ cần hiểu hoạt động của các driver như GPIO, SPI, I2C,.. Đơn giản như để config pin thì sẽ cần hiểu về device tree, pinctrl/gpio system & device tree bindings, khai báo default pinctrl status...
  • Làm về battery control thì sẽ cần tìm hiểu việc điều khiển power system, config charger, pmic - nhiều khi sẽ cần sửa hoặc porting driver của mấy con charger/pmic này từ code base của mấy dòng tương dương.
Nên làm embedded linux system đủ lâu và đủ sâu thì rồi cũng sẽ phải động tới kernel code thôi.
Team nhỏ thì họ lựa chọn dùng các platform open, support tốt từ cộng động, google.
Team lớn và sản phẩm chuyên biệt thì bắt buộc sẽ phải customize lại - thì hoặc lựa chọn trả tiền thuê support hoặc phải tự giải quyết vấn đề.
Chia sẻ nhanh của mình thôi - hơi lan man có thể ko giống ý mà chủ topic muốn đề cập. :D.
Click to expand...
Bác ơi bác có thể chia sẻ làm embedded linux tầng app thì sẽ làm những gì không ạ :D Em cũng đang học embedded linux hướng tới làm tầng app mà đang mông lung không biết mình phải học cái gì ạ :(
 
nhimngoc said:
Mình làm embedded linux - lớp app. Cái gì visible với user mới là selling point thôi. Kernel không phải cái user nhìn thấy và đặc thù của nó nên không phải cty nào của US/EU cũng đầu tư vào nguồn lực linux kernel - kể cả công ty rất to nhé - không phải là vì họ ko có tiền mà vấn đề là lượng công việc về kernel không nhiều - tuyển mấy bạn kernel expert về mà không có việc giao cho họ thì họ cũng sẽ ra đi thôi. Công việc liên quan đến kernel thường sẽ nhiều ở phase bringup board (thường ở EVB hoặc EVT) - nên việc nhiều trừ khi công ty có rất nhiều sản phẩm hw products được phát triển hàng năm (cái này không phải nhiều công ty) - đó là lý do phần hw design + bsp được outsource cho các cty design house ở Taiwan hoặc Trung Quốc nhiều - và các công ty focus vào application - phần core value của họ. Thường mình chọn SOC của hãng nào thì hãng đã có BSP riêng cho SOC, có vấn đề gì thì có thể get support từ hãng. Tất nhiên việc support này cũng có giới hạn - phụ thuộc vào volume của sản phẩm. Với các phân khúc mobile thì cỡ hàng chục triệu sản phẩm vẫn là nhỏ. Các công ty design house có mối quan hệ tốt với nhà cung cấp SOC - nên họ dễ get support hơn. Đó cũng là ưu điểm khi thuê các cty design house.
Nói như vậy không có nghĩa là phủ nhận việc cần hiểu linux kernel. Tuy nhiên linux kernel mình cũng không nghĩ nó khó đến nỗi không tiếp cận được. Nếu lập trình với MCU, RTOS rồi thì tiếp cận linux kernel cũng không khó. Bản chất vẫn là cần hiểu môi trường linux kernel code đang chạy trên đó. Các service mà linux kernel cung cấp không nhiều - quan trọng là hê sinh thái sống trong nó như USB subsystem, networking subsystem, audio/video subsystem,... Phần driver code mới là phần phức tạp nhất của linux kernel bởi nó dính tới đủ loại device khác nhau. Làm application mảng nào thì sẽ phải nắm rõ phần đó. Ví dụ:
  • Làm về interface thì sẽ cần hiểu hoạt động của các driver như GPIO, SPI, I2C,.. Đơn giản như để config pin thì sẽ cần hiểu về device tree, pinctrl/gpio system & device tree bindings, khai báo default pinctrl status...
  • Làm về battery control thì sẽ cần tìm hiểu việc điều khiển power system, config charger, pmic - nhiều khi sẽ cần sửa hoặc porting driver của mấy con charger/pmic này từ code base của mấy dòng tương dương.
Nên làm embedded linux system đủ lâu và đủ sâu thì rồi cũng sẽ phải động tới kernel code thôi.
Team nhỏ thì họ lựa chọn dùng các platform open, support tốt từ cộng động, google.
Team lớn và sản phẩm chuyên biệt thì bắt buộc sẽ phải customize lại - thì hoặc lựa chọn trả tiền thuê support hoặc phải tự giải quyết vấn đề.
Chia sẻ nhanh của mình thôi - hơi lan man có thể ko giống ý mà chủ topic muốn đề cập. :D.
Click to expand...
Cái bác nói là embedded Linux rồi. Nó cũng động vào kernel nhưng ở khối device driver thôi.
Kernel nó có nhiều module, trong đó có 1 module là device driver. Khối driver thì thiết kế theo đặc thù hardware.
Còn các khối còn lại thì thuần software, tư tưởng cũng khác hẳn nhau.
 
Z1r1t0 said:
Bác ơi bác có thể chia sẻ làm embedded linux tầng app thì sẽ làm những gì không ạ :D Em cũng đang học embedded linux hướng tới làm tầng app mà đang mông lung không biết mình phải học cái gì ạ :(
Click to expand...

Linux là OS, nó cung cấp môi trường cơ bản để các chương trình chạy trên đó . Mục đích của tầng app của embedded linux là để điều khiển thiết bị cung cấp các chức năng mà nó được thiết kế để chạy trên đó. Ở tầng app thì cơ bản do chạy trên linux nên giống hệt như phát triển app cho linux trên X86 thôi - chỉ là phần biên dịch thay vì là cho x86 thì có thể là họ CPU khác (ARM/MIPS/PowerPC/...)..
Nên lập trình tầng app không khác gì như cho desktop , app có thể là native app (C/C++, golang, assembly), chạy qua VM (java, scala), scripting (shell/python/perl), web app trên nền httpd server cho embedded (như uhttpd chẳng hạn),... Tất nhiên để hiểu sâu thì cần hiểu linux là gì - để hiểu thì cần hiểu low level services của nó - nên C/C++ là tiếp cận tốt, bạn có thể tham khảo 1 số tài liệu general cho lập trình linux :

Có một số điểm khác chút:
- Sẽ có nhiều trường hợp cần interface với low-level code hoặc kernel module service - nên kiến thức về system API là cần thiết (http://index-of.es/OS/Linux System Programming.pdf) - lý do tại sao C/C++ thường hay sử dụng - tuy nhiên linux kernel hiện đại thường cố gắng export function thông qua file system - nên việc điều khiển ngoại vi ví dụ như GPIO có thể đơn giản qua write/read trên 1 export file (ví dụ
/sys/class/gpio/gpioXX) - nên có thể dùng các ngôn ngữ hiện đại như golang cũng có thể tương tác với low level function qua read/write file hoặc qua việc call xuống C library (sử dụng cgo)
  • Thiết bị nhúng sẽ thường rất limit về khả năng UI (ví dụ có thể ko có màn hình - tất nhiên càng ngày các thiết bị nhúng càng mạnh và việc trang bị 1 màn LCD là bình thường), memory, ... nên rất nhiều thư viện về UI (ví dụ QT/GTK... có thể sẽ bị lược bỏ hoặc thay thế bởi 1 thư viện GUI đơn giản hơn).
  • Thường sẽ là ở dạng các daemon tự start bởi init system - cần tìm hiểu quy trình boot, và init system (systemV/systemd/upstart...) để hệ thống có thể tự khởi động các service cần thiết mà không cần user click chuột như trên PC
  • Làm với embedded system thì ko chỉ đơn giản là hiểu về lập trình, cần hiểu tổ chức bộ nhớ, cách đóng gói firmware - có nhiều công cụ hỗ trợ việc này như busybox, buildroot, yocto - cần tìm hiểu nó là gì, và cố gắng làm quen với nó.
  • Khi đã quen rồi thì sẽ biết quy trình từ build code rồi đóng gói ra file firmware cuối cùng rất là lâu (tính hàng nhiều giờ để build được 1 file firmware hoàn chỉnh) - với team lớn thì chi phí này khá là bự... Lúc này thì làm quen với docker/jenkins , CI/CD để tạo một pipeline tự động generate ra firmware khi user commit code.
  • Khi đã có tạo được 1 pipeline cơ bản này thì bắt đầu focus vào code chức năng chính nhé :D.

Ko có nhiều time nên quick notes thôi. Hi vọng có vài keyword cho bạn google thêm.
Tóm lại là học lập trình C/C++ cho Linux là apply được cho cả Desktop Linux và Embedded Linux. :D
 
PhuThoDien said:
Cái bác nói là embedded Linux rồi. Nó cũng động vào kernel nhưng ở khối device driver thôi.
Kernel nó có nhiều module, trong đó có 1 module là device driver. Khối driver thì thiết kế theo đặc thù hardware.
Còn các khối còn lại thì thuần software, tư tưởng cũng khác hẳn nhau.
Click to expand...
Driver thì cũng là software thôi - chẳng qua nó có cấu trúc riêng module do linux quy định - và hoạt động trong cùng kernel space với linux kernel. Nó cũng dạng như plugin và follow theo life-cycle do môi trường nó chạy quy định. Cũng khác gì android activity có life cycle quy định bởi android environment đâu : onCreate(), onStart(), onResume(), onPause(), onStop(), and onDestroy().
Chẳng qua nó crash thì cả system crash, tài nguyên CPU/memory trong nó cũng bị giới hạn, blabla... Nên yêu cầu quality về code cao hơn code ở application.
Còn đặc thù hardware khác nhau thì cũng khác chi các SW khác nhau có dặc thù khác nhau do business khác nhau. Nói ra thì chắc lâu không hết. Mình cũng không phủ nhận nó không khó, chỉ là chia sẻ cách tiếp cận của mình :D
 
PhuThoDien said:
Các dev về Linux kernel ở VN họ sẽ kiếm tiền bằng cách nào?

Thường đa số sẽ làm về embedded Linux. Con số này chiếm trên 99%. Như ở HN thì số lượng job làm về embedded Linux/Android tương đương với embedded MCU, realtime OS. Lương bên mảng embedded ngang hoặc thấp hơn chút so với bên app, mà embedded học lại cực hơn. Nói chung ai đam mê điện tử thì theo. Embedded thì công nghệ nó thay đổi chậm hơn, coi như là 1 điểm cộng.

Em cũng làm embedded device driver tầm 3 năm. Em không giỏi về hardware nhưng tính cần cù nên dần dần cũng làm được.

Thế còn 1% còn lại ví dụ như em thì sẽ kiếm tiền bằng cách nào. Em đưa ra con số 1% thì theo em biết hiện tại ở HN chỉ có 2 dự án làm thuần về kernel/custom Linux OS. Em đang làm việc tại 1 trong 2 dự án đó. Mảng này nếu muốn tuyển dev từ ngoài vào thì xác định là phải đào tạo, mức độ nhiều hay ít tuỳ từng người. Em chưa từng gặp dev nào có kinh nghiệm cũng như mục tiêu làm về Linux kernel giống như em ở HN cả. Ở trong Sài Gòn không biết có bác nào không. Nghề này ở VN cũng hẹp, ít chỗ nhảy việc nên các bạn khác có join vào dự án thì họ cũng không khoái lắm.

Cũng vì thế nên member như em được công ty rất quý, tạo mọi điều kiện cho em làm việc được thoải mái. Lương cũng ổn. Thu nhập mỗi tháng của em tầm 100 trước thuế, đến từ những nguồn sau:
1. Lương.
2. Đi dạy embedded Linux cho các cty khác. Học viên của em đa số là các bạn dev làm về embedded. Họ có back ground tốt về hardware. Người ít thì 1, 2 năm kinh nghiệm, người nhiều thì 10 - 20 năm cũng có. Có khá nhiều bạn đang làm ở nước ngoài như us, eu, jav. Mỗi lớp có tầm 20% học viên đang làm ở nước ngoài. Việc đi dạy ngoài kiếm tiền thì nó còn khá vui nữa. Em được kể chuyện và lan toả đam mê của mình cho người khác.
3. Support các cty khác. Chủ yếu là mảng embedded Linux. Tuy nhiên khi người ta tìm đến em thì họ đã khoanh vùng công việc liên quan đến hệ điều hành rồi. Ví dụ như giảm kích thước hệ điều hành, giảm thời gian boot, viết driver... Việc ở ngoài thì em ít khi code trực tiếp mà đa số đưa ra ý tưởng, thiết kế rồi thuê lại đội dev của em làm.

Em làm vì đam mê là chủ yếu chứ không quá nặng nề về tài chính. Nên tuy làm nhiều việc một lúc nhưng cũng không quá vất vả vì em bỏ tiền ra thuê người làm cũng nhiều. Ngày làm khoảng 8h + tự học 1 - 2h. Tuần làm tầm 6 ngày. Từ thứ 2 - 6 + 1 ngày chủ nhật.

Nếu ở Vn có nhiều người làm về kernel giống em thì công việc của em sẽ tốt hơn hay xấu đi? Mình nghĩ là sẽ tốt hơn. GDP của nước mình thấp nên mảng lập trình này vẫn luôn là việc thừa người thiếu. Em thấy 1 số dự án làm về OS mở ra rồi lại đóng vì không tuyển được người hoặc người làm không đảm bảo chất lượng.

Em sẽ có 1 bài viết khác giải thích cụ thể hơn các dự án về Linux kernel ở VN họ sẽ làm gì?
Click to expand...
Làm device driver ko phải là làm linux kernel hả bác ?
Chờ bài viết về các dự án linux kernel ở việt nam của bác . ráng viết mau để a e hiểu thêm nha bác.
 
Mình đang làm mảng autosar. Giờ trend của automotive cũng là mấy con ECU khủng bố chạy linux như kiểu qnx.
Mình muốn tự học thêm mảng này.
Có bác nào biết khóa học lập trình linux nào mà k cần hardware không chỉ mình với?

Sent from Xiaomi M2007J20CG using vozFApp
 
LuuKienMinh said:
Mình đang làm mảng autosar. Giờ trend của automotive cũng là mấy con ECU khủng bố chạy linux như kiểu qnx.
Mình muốn tự học thêm mảng này.
Có bác nào biết khóa học lập trình linux nào mà k cần hardware không chỉ mình với?

Sent from Xiaomi M2007J20CG using vozFApp
Click to expand...
Oh, bạn làm adaptive autosar rồi à? hay chạy mấy con SOC tích hợp cả realtime core + performance cores - có classic autosar chạy trên realtime-core? Lập trình linux thì cứ cài mấy distro phổ biến(ubuntu, debian,...) rồi code trên đó thôi. Đâu cần hw gì. Adaptive Autosar thì learn C/C++ như thường, và học các system service cung cấp bởi linux thôi, và học các thư viện phổ biến trên linux. Chú ý mấy cái IPC - hệ thống thường chạy gồm nhiều service khác nhau, và các service sẽ ko thể chạy độc lập được - nên communicate giữa các service(qua IPC) là rất quan trọng - ví dụ như Dbus. Genivi nó cũng define 1 thư viện phổ biên cho việc này là https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=5472311 - có binding dựa trên Dbus.
 
Dự án driver mới tinh được build từ A-Z trong đời của tôi là viết cho con máy điện tim, đang làm dở với team được 40% thì lại nhảy sang dự án khác. Mả cha nó 10 năm trong nghề tôi éo có cơ hội làm một dự án nào build từ đầu. Phần nào ngon bọn Tây với mấy thằng Tàu nó xơi sạch. còn đâu fix Bug là mấy gã tây nó đẩy về cho mấy nước như VN, Ấn kiếm tý xương mà nấu cháo ăn.

Nói chung chém lý thuyết ngành này trên zời dưới biển, cả sáng lẫn đêm k thể hết được. Còn làm thực tế tại VN nói chung toàn là bảo trì hệ thống chán vẹo :( Tôi đang muốn nhảy ra lắm rồi. Quanhđi quẩn lại cũng 30t mẹ nó rồi,thôi cố làm vài năm rồi ra làm tự do hoặc nốt năm nay ra làm tự do. Chán và chán vl rồi

Ai thật sự siêu nhân embedded thì cố nhồi cái IELTS 7.+ mà kiếm suất định cư châu Âu rồi nhảy mẹ nó vào viết nhúng cho quốc phòng, tên lửa với vệ tinh. Lương cao bổng nhiều mà oách vl
 
Last edited:
cs_50i said:
Dự án driver mới tinh được build từ A-Z trong đời của tôi là viết cho con máy điện tim. Mả cha nó 10 năm trong nghề tôi éo có cơ hội làm một dự án nào build từ đầu. Phần nào ngon bọn Tây với mấy thằng Tàu nó xơi sạch. Bug là mấy gã VN, Ấn nó đẩy về cho mà kiếm tý xương mà nấu cháo ăn.

Nói chung chém lý thuyết ngành này trên zời dưới biển, cả sáng lẫn đêm k thể hết được. Còn làm thực tế tại VN nói chung toàn là bảo trì hệ thống chán vẹo :( Tôi đang muốn nhảy ra lắm rồi
Click to expand...
Oh, mình chia sẻ dựa trên kinh nghiệm thức tế mình làm nhé, cách đây 5-6 năm thì đúng thật là như bạn nói, mình hồi đó làm outsource nên toàn làm mấy dự án dạng maintainance, bug fix. Sau đó may mắn gặp nhiều khách hàng dạng startup - có cơ hôi làm engineering nhiều hơn. Rồi sau nhảy ra ngoài làm công ty product - nên được làm nhiều công đoạn từ đầu như từ specification definition đến system architecture. Giờ cơ hội nhiều hơn rồi bạn ơi, cảm thấy tự tin thì kiếm job remote hoặc freelancer. Trong SG nhiều cơ hội hơn HN (mình đoán bạn ở HN).
 
nhimngoc said:
Oh, mình chia sẻ dựa trên kinh nghiệm thức tế mình làm nhé, cách đây 5-6 năm thì đúng thật là như bạn nói, mình hồi đó làm outsource nên toàn làm mấy dự án dạng maintainance, bug fix. Sau đó may mắn gặp nhiều khách hàng dạng startup - có cơ hôi làm engineering nhiều hơn. Rồi sau nhảy ra ngoài làm công ty product - nên được làm nhiều công đoạn từ đầu như từ specification definition đến system architecture. Giờ cơ hội nhiều hơn rồi bạn ơi, cảm thấy tự tin thì kiếm job remote hoặc freelancer. Trong SG nhiều cơ hội hơn HN (mình đoán bạn ở HN).
Click to expand...
SG thì đúng là nhiều hơn thật, làm 1 cty lâu rồi tôi ngại nhảy việc vì cũng k ham embedded nữa. Làm mấy dạng startup thì k còn sức lăn xả như xưa. Giờ ngồi máy tối đa được mấy tiếng là tôi oải rồi.
 
À mà đang có job maintainance cho con máy siêu âm 5 chiều. Ae nào có kinh nghiệm thì ới tôi, tôi đang có người nhờ tìm nhân tài. Rao lương net $2,5k nhưng chưa rõ deal lại thì thế nào.
 
cs_50i said:
SG thì đúng là nhiều hơn thật, làm 1 cty lâu rồi tôi ngại nhảy việc vì cũng k ham embedded nữa. Làm mấy dạng startup thì k còn sức lăn xả như xưa. Giờ ngồi máy tối đa được mấy tiếng là tôi oải rồi.
Click to expand...
Làm một thứ mãi cũng chán mà. Nên tự challenge mình thôi. Tôi cũng làm low-level với MCU programming từ đầu, làm mấy năm xong thấy chán nên nhảy lên làm lớp cao hơn lên embedded linux, Desktop App, cả blockchain. Làm lớp cao mang lại tầm nhìn rộng hơn là chỉ làm low-level, giúp hiểu ra rất nhiều thứ mà khi làm low-level mình ko biết tại sao nó vậy. Giờ ngôn ngữ lập trình không phải giới hạn rồi. Hướng giải quyết vấn đề thôi. Mình có nền tảng ổn thì làm gì cũng được thôi. Đó là lý do tại sao đội FAANG interview đâu có focus vào một ngôn ngữ hay framework cụ thể đâu. Khi kiến thức về Computer Science nắm vững rồi thì việc adapt với 1 ngôn ngữ hay framework đâu có vấn đề gì. Dù đang làm embedded linux, nhưng cũng đâu ngại làm desktop app, backend hay mobile app nếu có cơ hội. Trước rảnh còn kiếm job freelancer làm golang. :D
 
nhimngoc said:
Oh, bạn làm adaptive autosar rồi à? hay chạy mấy con SOC tích hợp cả realtime core + performance cores - có classic autosar chạy trên realtime-core? Lập trình linux thì cứ cài mấy distro phổ biến(ubuntu, debian,...) rồi code trên đó thôi. Đâu cần hw gì. Adaptive Autosar thì learn C/C++ như thường, và học các system service cung cấp bởi linux thôi, và học các thư viện phổ biến trên linux. Chú ý mấy cái IPC - hệ thống thường chạy gồm nhiều service khác nhau, và các service sẽ ko thể chạy độc lập được - nên communicate giữa các service(qua IPC) là rất quan trọng - ví dụ như Dbus. Genivi nó cũng define 1 thư viện phổ biên cho việc này là https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=5472311 - có binding dựa trên Dbus.
Click to expand...

Cty mình có hết bác ạ. Nhưng mình chỉ bsw trên uC thôi. Chỉ là thấy mấy product khác họ toàn dùng soc 1 con real time classic autosar và một con performance core dùng linux chứ k phải adaptive autosar nên mình muốn học thôi. Giờ các hãng xe họ cũng chuyển qua dùng domain controler của huawei hay nvidia giống như cái mô hình trên rồi.

Sent from Xiaomi M2007J20CG using vozFApp
 
nhimngoc said:
Oh, bạn làm adaptive autosar rồi à? hay chạy mấy con SOC tích hợp cả realtime core + performance cores - có classic autosar chạy trên realtime-core? Lập trình linux thì cứ cài mấy distro phổ biến(ubuntu, debian,...) rồi code trên đó thôi. Đâu cần hw gì. Adaptive Autosar thì learn C/C++ như thường, và học các system service cung cấp bởi linux thôi, và học các thư viện phổ biến trên linux. Chú ý mấy cái IPC - hệ thống thường chạy gồm nhiều service khác nhau, và các service sẽ ko thể chạy độc lập được - nên communicate giữa các service(qua IPC) là rất quan trọng - ví dụ như Dbus. Genivi nó cũng define 1 thư viện phổ biên cho việc này là https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=5472311 - có binding dựa trên Dbus.
Click to expand...
Adaptive Autosar có khác gì linux thường không bạn?
Mình đọc overview thì chỉ thấy nó là distro dành cho automotive.
Nhưng có những điểm khác thì mình không biết. Với cả tại sao phải sinh ra nó.
 
PhuThoDien said:
Một lĩnh vực hẹp mà nhiều thím đang làm về lập trình cũng không biết nó là cái gì.
Hệ điều hành bao gồm 2 khối, khối bên ngoài là tầng application tương tác với người dùng, khối bên trong là tầng nhân - kernel. Kernel phụ trách những công việc quan trọng như lập lịch, quản lý phần cứng.

Ở Việt Nam thì gần như không có job về mảng này, đơn giản là nước ta không tự làm được hệ điều hành, và cũng không tham gia phát triển những hệ điều hành open source như Linux và Android. Đôi khi cũng có những dự án yêu cầu can thiệp vào tầng nhân, nhưng thường chết yểu vì không có người làm được. Cũng may là có mảng embedded Linux gỡ gạc lại. Embedded Linux muốn làm được thì cần 1 phần nhỏ kiến thức về nhân. Cụ thể là cần hiểu về module driver - một trong số nhiều khối của kernel. Như mình thấy hiện tại thì nhiều bạn sinh viên đã biết về xu thế công nghệ trong lĩnh vực embedded đang chuyển dịch từ thuần vi điều khiển sang sử dụng Linux hoặc Android. Nên nhiều bạn cũng mày mò học về cách code driver trên Linux.

Làm về embedded Linux thì cần kiến thức tốt về hardware, lập trình vi điều khiển. Bản thân mình lại xuất thân từ software application. Mình cũng có nhiều kinh nghiệm làm về embedded, hiện tại nếu theo embedded thì lương cũng rất ổn. Tuy nhiên mình luôn ước mơ 1 ngày nào đó sẽ có cơ hội làm chung team với những chuyên gia về Linux kernel của thế giới. Nếu theo hướng embedded thì giấc mơ này sẽ không bao giờ thành hiện thực được. Tạm hiểu là nếu theo embedded Linux, device driver thì mình chỉ có thể đạt level senior developer chứ không thể lên mức expert được.

Tính đến hiện tại, mình đã học về kernel được gần 10 năm. Từ hồi bắt đầu đi làm đến giờ mình đều làm việc xoay quanh nó, về nhà lại dành thêm 1 - 2 tiếng để tự học thêm. Tiếng anh mình giao tiếp cũng tốt. Mình nghĩ hiện tại ở VN khó có ai am hiểu về lĩnh vực này hơn mình. Nếu như nó là một công nghệ phổ biến như lập trình app, web hoặc AI thì mình đã có rất nhiều đất để diễn. Tuy nhiên tình trạng của mình hiện tại nó giống như kiểu hoạ sĩ vẽ tranh đem bán ở làng quê vậy.

Nhiều bạn sẽ hỏi tại sao mình không đi nước ngoài làm việc. Kể cả ở những nước phát triển thì số lượng công ty làm về cái này cũng không nhiều. Thường là những công ty thuôc dạng khủng như kiểu Google, Facebook, Amazon... họ mới làm. Để join vào những công ty này một là bạn phải đi học ở trường top rồi thực tập và làm việc giống như Fresher ở Việt Nam. Cửa thứ 2 là bạn là chuyên gia trong lĩnh vực đó, đã có nhiều kinh nghiệm, bạn phỏng vấn và vào thẳng dự án. Vấn đề của mình nằm ở đây, mình đã có gia đình và quá già cho cách một nhưng lại không có đủ skill và kinh nghiệm để vào bằng cách 2. Mình làm về kernel ở VN được gần 10 năm, nhưng đa số công việc cũng chỉ sử dụng kiến thức về kernel chứ không phải trực tiếp phát triển nó. Mà cái những công ty kia yêu cầu là kinh nghiệm phát triển trực tiếp những đoạn code nằm trong nhân.

Nếu bây giờ mình tạm gác ước mơ lại. Tiêp tục làm về embedded, học nâng cao thêm kiến thức về phần cứng. Mình sẽ có một mức lương cao ở VN. Nếu muốn đi nước ngoài làm việc chắc cũng không khó vì học sinh của mình có nhiều bạn đang làm ở nước ngoài. Có thể nhờ họ giới thiệu cho vào làm cùng công ty.

Nhưng cuộc sống này ai cũng chỉ được sống một lần, mình muốn cố gắng hết sức để sau này khi về già không phải hối tiếc. Vậy nên mình vẫn chọn đi tiếp con đường chông gai. Thời gian tới mình sẽ làm những video training Linux kernel bằng tiếng anh, tìm cách tham gia vào phát triển Linux kernel cùng với community của họ, tất nhiên là không được đồng nào cả. Hi vọng sau vài năm nữa, mình sẽ có được mối quan hệ với các developer đang phát triển nhân Linux kernel. Từ đó có thể sang nước ngoài và làm việc cùng họ.

Linux kernel có gì mà mình lại yêu thích nó đến vậy? Đơn giản là do mình có cảm giác quen thuộc với nó, giống như đôi bàn tay của mình. Hoặc mỗi khi có ai đó hỏi mình về một vấn đề khó khăn mà họ bế tắc cả tháng trời, mình lại nhanh chóng đưa ra một cách giải quyết đơn giản. Lúc đó mình có cảm giác là họ ngạc nhiên giống như mình đang làm ảo thuật vậy. Có thể kể ra một vài câu chuyện khá buồn cười sau đây:

1. Bạn A code hàm đọc dữ liệu từ phần cứng. Hệ thống thỉnh thoảng bị crash. Sau một thời gian dài debug thì bạn ý phát hiện là lỗi liên quan đến con trỏ truy cập vào vùng nhớ không hợp lệ. Bạn ý check lại tất cả những đoạn code gọi hàm malloc, tất cả các con trỏ đều kiểm tra khác NULL trước khi sử dụng. Nhưng thỉnh thoảng bug vẫn xuất hiện. Khi bạn ý hỏi mình, mình bảo bạn ý là nên thay hàm malloc bằng hàm calloc, bạn ý làm theo và bug biến mất.
2. Thiết bị sau khi xuất xưởng được chạy test tự động, sau vài ngày chạy test thì ngẫu nhiên có 1 thiết bị bị khởi động lại. Khách hàng bắt team ở VN kiểm tra, team ở VN cũng không biết tại sao. Bug có log nhưng lại không tái hiện lại được. Team thử upgrade kernel version lên thì thấy chạy test không bị lỗi đấy nữa. Dò theo log cũ thì phát hiện ra 1 commit trong kernel nhìn có vẻ liên quan đến việc fix bug đó. Nhưng đọc commit message mãi không hiểu được họ nói gì. Cả team khách hàng bên Nhật lẫn đội bên VN đều chịu. Mà bug nó xuất hiện ngẫu nhiên với tần xuất nhỏ, nên cũng không ai dám chắc là đã được fix thật chưa. Về sau họ gửi mail hỏi khắp cty xem có ai biết về Linux kernel không để support. Mình đọc commit message, tìm hiểu các khái niệm xung quanh rồi giải thích cho họ. Sau đó mình tái hiện được lại bug. Từ đấy họ gọi mình là super man. Về sau có 1 lần khách hàng họ sang họp, họ gọi mình vào để giới thiệu mặc dù không cùng dự án. Họ trong Sài Gòn còn mình ở HN.
3. Hàm gettimeofday() trong thư viện của C bị lỗi memory leak. Bạn dev đó fix 2 tháng lỗi memory leak mà không biết nguyên nhân vì đâu. Quan trọng là ngay từ ban đầu không ai nghĩ các hàm của libc có thể bị lỗi này, nên lúc review code mặc định chúng ta bỏ qua. Về sau mình hướng dẫn bạn ý dò ra được lỗi, sau đó report lại cho bên làm trình biên dịch của hãng chip để họ fix.
4. Ngoài ra thì còn vô số những kỷ niệm buồn cười khác, có cái mình nhớ và có cái mình quên rồi.

Nói chung nếu không tính embedded Linux thì Linux kernel không phát triển ở Việt Nam. Vì theo nghề này mà mình cũng có nhiều kỷ niệm vui buồn lẫn lộn. Nhưng trên hết là nhờ nó mà mình được sống một cuộc sống có ý nghĩa, được quen biết nhiều người. Cũng có lúc thấy hơi nản vì con đường theo nó sao mà chông gai. Nhưng kệ thôi, còn sống là còn chiến đấu.

Nay tâm trạng chán đời nên bài viết lan man quá, cám ơn các bạn đã đọc bài.

P2: Các dev về Linux kernel kiếm tiền như thế nào?
Click to expand...
Anh Phú Xấu Xa ơi về kiến thức mạch, điện tử...Hardware thì anh học như thế nào trong vai trò là một software engineer?
 
snake_case said:
Anh Phú Xấu Xa ơi về kiến thức mạch, điện tử...Hardware thì anh học như thế nào trong vai trò là một software engineer?
Click to expand...
Anh làm module nào thì tìm hiểu về module đấy em à. Từ giao thức, hardware rồi cách cấu hình thanh ghi.
Nhưng thực sự thì đến hiện tại anh vẫn cảm thấy anh yếu về hardware. Tìm hiểu về hardware anh thấy phải đọc mãi mới hiểu.
 

Similar threads

duchm4125
thảo luận [Web] Sự kiện onkeydown bỗng dưng bị lỗi không nhận khi chuyển sang chế độ nhập tiếng Nhật
Replies
2
Views
269
mtl0612
mtl0612
Trungho1510
thắc mắc Lấy ý kiến về làm web record quỹ từ thiện
Replies
7
Views
393
venom25
venom25
tuanddd2
Có thím nào có job outsouce/freelace embedded linux/IoT không ạ
Replies
3
Views
321
buonsonho
buonsonho
khanhnamvn
thảo luận Sau 1 năm rưỡi làm app mình học được gì?
3 4 5
Replies
90
Views
8K
songao
songao
potay001
thảo luận [TÌM ĐỒNG ĐỘI] Phát triển chơi cờ vua trên Telegram
Replies
14
Views
793
TungDeTien24
TungDeTien24

Share this page

Back
Top